I’m seeing cases where select() is called and returns expected data but
_select_receive was never called??? How is that possible?
From my observation I’m guessing if there is already something on the file
descriptors passed to select, it returns without having called
_select_proxy. That’s kind of bad because it means messages priority are
ignored. In my case i’m doing a test case were there is lot of data
comming in the program via TCP/IP, but if the program can’t keep up, all the
other non TCP/IP related event (messages and proxy) are ignored.
Mario Charest postmaster@127.0.0.1 wrote:
I’m seeing cases where select() is called and returns expected data but
_select_receive was never called??? How is that possible?
From my observation I’m guessing if there is already something on the file
descriptors passed to select, it returns without having called
_select_proxy. That’s kind of bad because it means messages priority are
ignored. In my case i’m doing a test case were there is lot of data
comming in the program via TCP/IP, but if the program can’t keep up, all the
other non TCP/IP related event (messages and proxy) are ignored.
Yeah, that makes sense to me.
Basically, select does:
– for each fd, send message to server to say poll/arm (arm for notify
if poll says no data currently available)
– if no FD has polled data available
– block for notify (_select_receive)
– else
– return active FDs
If you’re only using sockets, you might consider SIGIO notification by
setting the sockets for asynchronous I/O, using a SIGIO signal handler that
triggers a proxy, and using a Receive() as your main blocking point. Also,
you’ll want to unmask SIGIO before Receive(), and re-mask it after.
(The proxy handles race conditions.)
If you get a SIGIO, you can then do a non-blocking select() [non-NULL
timeout pointer to a zero-valued timeout structure I think], to find
out which sockets.
By controlling the priority of the proxy, you can decide what priority
the TCP/IP stuff is relative to QNX stuff.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:dn9vmi$1n1$3@inn.qnx.com…
Mario Charest postmaster@127.0.0.1 wrote:
I’m seeing cases where select() is called and returns expected data but
_select_receive was never called??? How is that possible?
From my observation I’m guessing if there is already something on the
file
descriptors passed to select, it returns without having called
_select_proxy. That’s kind of bad because it means messages priority are
ignored. In my case i’m doing a test case were there is lot of data
comming in the program via TCP/IP, but if the program can’t keep up, all
the
other non TCP/IP related event (messages and proxy) are ignored.
Yeah, that makes sense to me.
Basically, select does:
– for each fd, send message to server to say poll/arm (arm for notify
if poll says no data currently available)
– if no FD has polled data available
– block for notify (_select_receive)
– else
– return active FDs
If you’re only using sockets, you might consider SIGIO notification by
setting the sockets for asynchronous I/O, using a SIGIO signal handler
that
triggers a proxy, and using a Receive() as your main blocking point.
Also,
you’ll want to unmask SIGIO before Receive(), and re-mask it after.
Interesting idea, thanks.
(The proxy handles race conditions.)
If you get a SIGIO, you can then do a non-blocking select() [non-NULL
timeout pointer to a zero-valued timeout structure I think], to find
out which sockets.
By controlling the priority of the proxy, you can decide what priority
the TCP/IP stuff is relative to QNX stuff.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com