|
| I'm building a network/socket based application and thought I'd give
realtime signals a go. I've gotten the application working so far on a linux
2.4 based system, but there are a few mysteries left uncovered, and I'm
severly lacking in documentation. If anyone can answer a few of the
following, that would definetly be appreciated.
1) Anyone know of any good coding examples / good documentation surrounding
POSIX.4 real time signals / real world implementations, specifically around
SIGIO would be great. I've scoured google with not too much luck.
Ok, now for the nitty gritty... Typically when coding non-realtime signals,
specifically the SIGIO signal, in the handler you poll to see which file
descriptors are ready and perform some form of action. You typically have
to "read" on these descriptors until there's nothing left to read since
signals won't queue and then you return. In real-time signals however, the
behaviour is a bit different. For one, in my current implementation I'm
setting SA_SIGINFO so that I'm notified which file descriptor the signal is
referring to. So here's the questions:
2) If multiple blocks of data are received on the socket, causing multiple
SIGIOs to be queued, when in the handler, how much will I "read"? In other
words, if 2 "blocks" of data are available on the socket before the first
SIGIO is caught and processed, and I were to read SSIZE_MAX worth of data
(assuming the data is smaller than that) in the first instance of the
handler, will I get both blocks of data in the first instance, and then
read -1/EGAIN when the queued SIGIO fired?
Since I somewhat ported my non-realtime version to the realtime version of
SIGIO, my current implementation reads everything there is before return by
issuing multiple "read"s until nothing is left, and then simply not caring
when "read" returns -1/EGAIN on successive queued SIGIOs on the same
descriptor, so again, it works fine, I'm just wondering if I have to, and if
I don't, will read only return the amount of data which originally triggered
the signal, however multiple reads will pull it all out?
3) 3rd and my most important question is, how to properly handle closed
sockets. I've noticed that after closing a socket, specifially from within
the signal handler, it is possible that there are still pending signals for
that descriptor, so after closing the socket, I still sometimes receive one
or two signals with si_fd pointing to the closed descriptor, and my read
will return EBADF. My worry is the following scenario...
I receive a packet causing a SIGIO. While in the handler, more data arrives,
causing a SIGIO to be queued. While in the first instance of the signal, I
decide to close the socket and open a new one. The new decriptor uses the
same descriptor as the one I just closed. When the queued signal fires, how
does one determine whether or not I'm reading stale data, or data from the
new socket.
4) So... when closing a socket, is there a way to flush any pending queued
signals for that descriptor?
Thanks in advance!
Mike
|
|