Re: non-blocking sockets, SIGIO and realtime signals
- From: Michael Kilburn <crusader.mike@xxxxxxxxx>
- Date: Fri, 31 Aug 2007 06:12:38 -0000
On Aug 31, 3:01 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
Michael Kilburn <crusader.m...@xxxxxxxxx> writes:
As I understood magic steps are:
- make socket non-blocking
- use fcntl with F_SETOWN and F_SETSIG to setup signals from 'realtime
signals' range
- provide proper signal handlers (taking reenterability stuff into
account, of course)
I'd say the intended usage of this facility is that you register one
RT signal and use the struct siginfo optionally passed to the handler
to demultiplex signals to file descriptor/ event pairs.
Hmm... I planned simply to use fd passed to my handler by signal.
Which raises another question -- is it possible to associate some user
data with socket? Something like this:
set_user_data(socket, (void*)pMySocketClass);
....
// then in handler:
SocketClass* pSocket = (SocketClass*)get_user_data(socket);
or I am doomed with maintaining static map<socket, Socket*>?
1. What happens if on socket side raising of signal fails?See <URL:http://www.kegel.com/c10k.html#nb.sigio>
Hmm, I've seen this document already... It does not state clearly what
is going to happen in this case. I could guess SIGIO will be sent
instead, but can't be sure 100%. Though I'd prefer for socket library
to close socket instead -- signal queue overflow means that server is
under too much load, client should go away and try later.
Let me explain what I am trying to do: there is a big system which
consists of many single-threaded applications that do all sorts of
things. I am trying to add monitoring functionality to them as
painlessly as possible -- i.e. I do not like the idea of changing app
structure to support some kind of message/poll loop since in many
cases it is simply not possible. And adding communications based on
signals & non-blocking sockets looks very attractive. Traffic is
supposed to be very small and in 99% of cases outgoing data will fit
into socket's buffer completely. But to address remaining 1% as well
as incoming data I need signal SIGIO-style signals.
In this light auto-close behavior socket can't send notification
signal looks much better. :-)
If your process catches a signal while it is blocked in a 'slow'
system call (one which can wait for an indeterminate amount of time,
eg network or terminal I/O), the system call will return with an error
code of EINTR unless automatically restarting it was requestion when
setting up the signal handler. The 'synchronous I/O multiplexing
routines' (select/ poll) are an exception to this: They will always be
interrupted.
According to some man page I have seen sleep and write/read functions
are always interrupted regardless of SA_RESTART flag. read/write
simply return number of bytes received/written. Since all magic
libraries like iostreams at the end boil down to read/write calls -- I
am very interested if they restart these operations (logically they
should, but who knows?).
The source code will probably tell you this.
Source code shows only one possible implementation -- the question is
"do they always give this or that guarantee"?
Something to be aware of: When using edge-triggered I/O readiness
notification, a 'notification event' will occur whenever the state of
a descriptor changes from 'not ready' to 'ready'. Assuming a loop like
the pseudocode below:
while (1) {
fd = wait_for_input_on_some_fd();
while (read_input(fd, buffer) != EAGAIN)
process_input(buffer);
}
this means if you read all input available at the time you call
read_input into buffer and new input becomes available while
process_input is active, a signal will be queued for your process
which you will receive as soon as the inner loop terminates. With
sufficiently inconvenient timing, this can result in a lot of spurios
notifactions you have to process.
Hmm... true. Also this raises another question -- how to distinguish
if socket became available for reading or for writing?
Sincerely yours,
Michael.
.
- References:
- non-blocking sockets, SIGIO and realtime signals
- From: Michael Kilburn
- Re: non-blocking sockets, SIGIO and realtime signals
- From: Rainer Weikusat
- non-blocking sockets, SIGIO and realtime signals
- Prev by Date: How to select a socket on linux
- Next by Date: Re: How to select a socket on linux
- Previous by thread: Re: non-blocking sockets, SIGIO and realtime signals
- Next by thread: gtk_entry_set_text with pthread
- Index(es):
Relevant Pages
|
