Mirror of :pserver:cvs@cvs.fefe.de:/cvs libowfat https://www.fefe.de/libowfat/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

39 lines
1.6 KiB

.TH io_wait 3
io_wait \- wait for events
.B #include <libowfat/io.h>
void \fBio_wait\fP();
io_wait() checks the descriptors that the program is interested in to
see whether any of them are ready. If none of them are ready, io_wait()
tries to pause until one of them is ready, so that it does not take time
away from other programs running on the same computer.
io_wait pays attention to timeouts: if a descriptor reaches its timeout,
and the program is interested in reading or writing that descriptor,
io_wait will return promptly.
Under some circumstances, io_wait will return even though no interesting
descriptors are ready. Do not assume that a descriptor is ready merely
because io_wait has returned.
io_wait is not interrupted by the delivery of a signal. Programs that
expect interruption are unreliable: they will block if the same signal
is delivered a moment before io_wait. The correct way to handle signals
is with the self-pipe trick.
Depending on the underlying operating system primitive, there is a
potential race condition to be aware of. Some event notification
mechanisms (for example, kqueue on BSD and epoll on Linux) will return
multiple events. If your application operates on pairs of file
descriptors (a proxy server maybe), and an error on one descriptor
can lead to closing the other descriptor, then an outstanding event on
the other descriptor can still be queued for delivery to you. Be
prepared to receive events for a descriptor that has already been
io_waituntil(3), io_check(3), io_wantread(3), io_wantwrite(3), io_fd(3)