In QNX4 once could do a Creceive( proxyId, … ) to dequeue specific
proxies. Is there anything similar in QNX6? If not how are people managing
periodic timers which may queue several pulses before they can be handled. I
would like to log the number of pulses I had queued (if > 1) and then
process once.
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
In QNX4 once could do a Creceive( proxyId, … ) to dequeue specific
proxies. Is there anything similar in QNX6? If not how are people managing
periodic timers which may queue several pulses before they can be handled. I
would like to log the number of pulses I had queued (if > 1) and then
process once.
You can not dequeue specific pulses. What you could do is:
SIGEV_UNBLOCK_INIT( &ev );
do {
TimerTimeout( CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE, &ev, NULL, NULL );
rcvid = MsgReceivePulse(…);
while( 0 == rcvid );
Which will drain all pending pulses without blocking you when you run out
of pulses.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
But your method is not equalvalent to Creceuve(proxyId,…).
Actually I think Creceive() is a very useful API in QNX4. I wasn wondering
why
it is removed from Q6.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:b1n694$lg0$6@nntp.qnx.com…
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
In QNX4 once could do a Creceive( proxyId, … ) to dequeue specific
proxies. Is there anything similar in QNX6? If not how are people
managing
periodic timers which may queue several pulses before they can be
handled. I
would like to log the number of pulses I had queued (if > 1) and then
process once.You can not dequeue specific pulses. What you could do is:
SIGEV_UNBLOCK_INIT( &ev );
do {
TimerTimeout( CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE, &ev, NULL, NULL );
rcvid = MsgReceivePulse(…);
while( 0 == rcvid );Which will drain all pending pulses without blocking you when you run out
of pulses.-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Jerry <xwindow@yahoo.com> wrote:
But your method is not equalvalent to Creceuve(proxyId,…).
Actually I think Creceive() is a very useful API in QNX4. I wasn wondering
why
it is removed from Q6.“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:b1n694$lg0$> 6@nntp.qnx.com> …
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
In QNX4 once could do a Creceive( proxyId, … ) to dequeue specific
proxies. Is there anything similar in QNX6? If not how are people
managing
periodic timers which may queue several pulses before they can be
handled. I
would like to log the number of pulses I had queued (if > 1) and then
process once.You can not dequeue specific pulses. What you could do is:
SIGEV_UNBLOCK_INIT( &ev );
do {
TimerTimeout( CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE, &ev, NULL, NULL );
rcvid = MsgReceivePulse(…);
while( 0 == rcvid );Which will drain all pending pulses without blocking you when you run out
of pulses.
Can you establish multiple channels for multiple pulse sources?
Yes, I realize that this won’t scale well. But if you just need to
distinguish a few pulse sources as special this should work OK.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
Jerry <xwindow@yahoo.com> wrote:
But your method is not equalvalent to Creceuve(proxyId,…).
Yes, I know it isn’t. That’s why my first statement was “you can’t…”
then I presented the closest thing you could get.
Actually I think Creceive() is a very useful API in QNX4. I wasn wondering
why it is removed from Q6.
Because the architecture no longer allows it.
Under QNX4, you received from processes, and the parameter to Receive()/
Creceive() was a process id. Proxies also had entries in the process
table, and you could specify them as such. You also replied to processes.
Once you go multi-threaded, this no longer works. For instance:
Pid 5 - thread 1 and thread 2 are both REPLY blocked on your server.
If you Reply(5,…) which thread should be unblocked?
So, the pid based architecture of QNX4 could not work in a threaded
environment.
We went to a connection & channel abstraction based architecture, and with
it actually gained a fair bit of flexibility. We couldn’t, though, get
that nice side-effect of the single source Receive(), because the
connection → channel mapping is a many to one mapping.
The only way to uniquely drain pulses of one type, is to send them to
a unique channel of their own – but now you’ve lost the comfortable
multiplexing that blocking on MsgReceive() gives you. In essence, you
need (at least) one thread per channel in your server (else you end up
“polling” channels).
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Jerry <xwindow@yahoo.com> wrote:
But your method is not equalvalent to Creceuve(proxyId,…).
Actually I think Creceive() is a very useful API in QNX4. I wasn wondering
why
it is removed from Q6.
As far as I understood the new architecture, you can attach
a certain pulse handler for a certain pulse code (pulse_attach()).
Perhaps this covers your need …
Or do it with a second channel/thread?
Just my 0.02$,
Karsten.
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
Because the architecture no longer allows it.
Under QNX4, you received from processes, and the parameter to Receive()/
Creceive() was a process id. Proxies also had entries in the process
table, and you could specify them as such. You also replied to processes.Once you go multi-threaded, this no longer works. For instance:
Pid 5 - thread 1 and thread 2 are both REPLY blocked on your server.
If you Reply(5,…) which thread should be unblocked?So, the pid based architecture of QNX4 could not work in a threaded
environment.We went to a connection & channel abstraction based architecture, and with
it actually gained a fair bit of flexibility. We couldn’t, though, get
that nice side-effect of the single source Receive(), because the
connection → channel mapping is a many to one mapping.The only way to uniquely drain pulses of one type, is to send them to
a unique channel of their own – but now you’ve lost the comfortable
multiplexing that blocking on MsgReceive() gives you. In essence, you
need (at least) one thread per channel in your server (else you end up
“polling” channels).Ok but there is a MsgReceivePulse() which I assume means there is a way
to selectively receive based on rcvid, where rcvid=0 for a pulse. So could
this selective receive be extended to also check the pulse code when
rcvid=0?
There are work-arounds but what is the most common method for this
situation?
Do people ignore the situation and then when a flurry of pulses hit then do
their
thing for each one?
Cheers,
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
Ok but there is a MsgReceivePulse() which I assume means there is a way
to selectively receive based on rcvid, where rcvid=0 for a pulse. So could
this selective receive be extended to also check the pulse code when
rcvid=0?
MsgReceivePulse() doesn’t select on rcvid – it just tells the kernel
to only unqueue pulses.
It has no way to say “only unqueue pulses by pulse code”.
Also, under QNX4 – you lost time-ordering information for multiple
proxies. QNX 6 maintains time-ordering for pulses (if same priority).
It might not be impossible to write this function… it would require
implementing and verifying a new kernel call. It seems unlikely to
me that it would be done.
There are work-arounds but what is the most common method for this
situation?
Do people ignore the situation and then when a flurry of pulses hit then do
their thing for each one?
See earlier in the thread with my drain (all) pulses loop. In that loop,
you could collect a set of flags, set each flag for a pulse type you got,
then for each flag set, process that pulse type once.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Karsten.Hoffmann@mbs-software.de wrote:
Jerry <> xwindow@yahoo.com> > wrote:
But your method is not equalvalent to Creceuve(proxyId,…).
Actually I think Creceive() is a very useful API in QNX4. I wasn wondering
why
it is removed from Q6.As far as I understood the new architecture, you can attach
a certain pulse handler for a certain pulse code (pulse_attach()).
Perhaps this covers your need …
pulse_attach() is quite different – that is in the resource manager
situation.
In that case, your pulse function will get called for EVERY pulse
queued to that resource manager. Better not fall behind, you can’t
safely clean up in that case.
Or do it with a second channel/thread?
That’s about your best hope in a resource manager environment if you
think there is an appreciable risk of having to do such a cleanup of
missed pulses.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David,
First, thanks for the discussion. In case it’s not stated enough I think
your
presence here in these newsgroups is a big + for the QNX community.
It reminds me of earlier days on QUICS.
More below …
It might not be impossible to write this function… it would require
implementing and verifying a new kernel call. It seems unlikely to
me that it would be done.
I think this type of function would be extremely beneficial to the
community.
Count me as a vote for the addition of such function to a future release. I
would
like to see both a blocking and non-blocking versions.
David,
First, thanks for the discussion. In case it’s not stated enough I think
your
presence here in these newsgroups is a big + for the QNX community.
It reminds me of earlier days on QUICS.
I totally agree!
Marty Doane
Siemens Dematic
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
proxies. Is there anything similar in QNX6? If not how are people managing
periodic timers which may queue several pulses before they can be handled. I
Would it be feasible for you to use POSIX timers? timer_getoverrun()
exactly does what you need to.
-Gerhard
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid’s vuasichdig, und lossds eich nix gfoin!
| – Dr. Kurt Ostbahn
This looks promising … but I would rather avoid signals if possible. I
wonder if pulses act the same way?
“Gerhard Wesp” <gwesp@cosy.sbg.ac.at> wrote in message
news:b2d3vq$epf$3@inn.qnx.com…
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
proxies. Is there anything similar in QNX6? If not how are people
managing
periodic timers which may queue several pulses before they can be
handled. IWould it be feasible for you to use POSIX timers? timer_getoverrun()
exactly does what you need to.-Gerhard
| voice: +43 (0)676 6253725 *** web: > http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid’s vuasichdig, und lossds eich nix gfoin!
| – Dr. Kurt Ostbahn
David Gibbs <dagibbs@qnx.com> wrote:
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
This looks promising … but I would rather avoid signals if possible. I
wonder if pulses act the same way?No. Just signals.
Use one of the RT signals, keep it masked except when you block,
and block using sigwaitinfo() could give some flexibility (and
without the nasty if (errno == EINTR) problems.)
LOL I gotta say something. Everyone is afraid to use signals. Write
your first signal handler. Play with it. Have fun with it. Enjoy it.
Once you loose your virginity the pain goes away and you’ll find it
doesn’t hurt anymore. (That’s what cut & paste is for.)
Sometimes, it really is the right tool for the job. Watermellon is
great. But I wouldn’t want to have to use it to cut lumber with one.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
This looks promising … but I would rather avoid signals if possible. I
wonder if pulses act the same way?
No. Just signals.
Use one of the RT signals, keep it masked except when you block,
and block using sigwaitinfo() could give some flexibility (and
without the nasty if (errno == EINTR) problems.)
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
This looks promising … but I would rather avoid signals if possible. I
Why? What’s wrong with signals?
You might even get away without installing a signal handler, if you use
sigwaitinfo().
-Gerhard
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid’s vuasichdig, und lossds eich nix gfoin!
| – Dr. Kurt Ostbahn