rbanos@mtecv2.mty.itesm.mx (Roberto A. Banos Alvarez) (06/08/91)
I have a process that has to listen for streams and datagrams. Obviusly, (I think) I can't have a blocking-accept for either stream or datagram msg. So, I decided to have two different sockets with non-blocking accepts and a loop with a select to test if there's a message pending. This works OK, but it loads the system. Is there a way to optimize this? Maybe generating a signal when a message arrives... If so, please send me a short example. Thank you in advance for any help!!! Roberto rbanos@mtecv2.mty.itesm.mx rbanos@next00.mty.itesm.mx
mycroft@kropotki.gnu.ai.mit.edu (Charles Hannum) (06/08/91)
In article <3449@mtecv2.mty.itesm.mx> rbanos@mtecv2.mty.itesm.mx (Roberto A. Banos Alvarez) writes:
I have a process that has to listen for streams and datagrams. Obviusly,
(I think) I can't have a blocking-accept for either stream or datagram msg.
So, I decided to have two different sockets with non-blocking accepts and
a loop with a select to test if there's a message pending. This works OK, but
it loads the system.
If you use NULL for the timeout argument to select(2), it should wait
for one of the file descriptors to become ready. If you pass it a
pointer to an integer set to 0, it will exit immediately. Setting the
files to non-blocking I/O should not make any difference.torek@elf.ee.lbl.gov (Chris Torek) (06/09/91)
In article <MYCROFT.91Jun8022148@kropotki.gnu.ai.mit.edu> mycroft@kropotki.gnu.ai.mit.edu (Charles Hannum) writes: >If you use NULL for the timeout argument to select(2), it should wait >for one of the file descriptors to become ready. If you pass it a >pointer to an integer set to 0, it will exit immediately. Setting the >files to non-blocking I/O should not make any difference. Actually, that is a `pointer to a struct timeval'. This is otherwise correct. Select is not supposed to base its `readiness' decision on blocking/nonblocking modes; however, there have been some implementation goofs in the past in this respect. If you are stuck with one of those you might have to clear nonblocking mode for the duration of the select call. In general, there is no reason to mix select and nonblocking I/O: since select tells you which descriptors will not block, you can simply avoid operations on those descriptors. There are special cases, though (shared descriptors, e.g.). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/16/91)
In article <14075@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: > In general, there is no reason to mix select and nonblocking I/O: > since select tells you which descriptors will not block, you can > simply avoid operations on those descriptors. There are special > cases, though (shared descriptors, e.g.). Ummm, what about writing? Even when a select() indicates write-ready for a descriptor, a write() can still block, under circumstances which a user-level program cannot readily determine and probably cannot (at all) portably determine. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu