Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
[...]
> That works! Both FASYNC and FIOASYNC clauses cure the problem. Because
> the tracefiles created by this cases looks very similar, I can not say
> which is better.
I think somebody should write an autoconf test to check which of
these actually works. What would nice to find out is why glibc
defines these ioctl when it doesn't support them?
I don't know how to classify the I_GETSIG/I_SETSIG ioctl's. The header
says
-------------------------------
#define I_SETSIG 6 /* Inform the STREAM head that the process
wants the SIGPOLL signal issued. */
#define I_GETSIG 7 /* Return the events for which the calling
process is currently registered to be sent
a SIGPOLL signal. */
-------------------------------
and libc.info
-------------------------------
- Macro: int SIGIO
This signal is sent when a file descriptor is ready to perform
input or output.
On most operating systems, terminals and sockets are the only
kinds of files that can generate `SIGIO'; other kinds, including
ordinary files, never generate `SIGIO' even if you ask them to.
In the GNU system `SIGIO' will always be generated properly if you
successfully set asynchronous mode with `fcntl'.
- Macro: int SIGPOLL
This is a System V signal name, more or less similar to `SIGIO'.
It is defined only for compatibility.
-------------------------------
Because of the comment at I_SETSIG (*STREAM*), I guess it can be used
just with streams but not with sockets.
You can read in the SIGIO description, the prefered way to generate
the signal is setting asynchronous mode with 'fcntl'
Do you have the glibc info files?
Yes, but I have not found much information about the usage of signals
in conjunction with sockets.
Do they say something about these settings?
I have grep'ed all my info-files and man-pages but have not found
anything about I_[SG]ETSIG.
Enrico
--
eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de
talk: ensc(a)ultra.csn.tu-chemnitz.de