I'm trying to write a server application that will wait for incoming connections.
Whenever a client attempts to connect/read/write (basically when the socket
experiences activity) a signal is supposed to be triggered.
fcntl(socket, F_SETSIG, SIGIO);
fcntl(socket, F_SETFL, O_ASYNC | O_NONBLOCK);
fcntl(socket, F_SETOWN, getpid());
struct sigaction action;
action.sa_sigaction = &MySigHandler;
action.sa_flags = SA_SIGINFO;
sigaction(SIGIO, &action, NULL);
According to the man pages, whenever there is activity in the socket "socket", a
signal will be raised. The signal would be handled by "MySigHandler", and since
the "SA_SIGINFO" flag was set, the signal would provide additional information
to the function. And here is when the unexpected behaviour occurs.
According to the manpages, the second parameter of the handler (siginfo_t *)
should contain additional information. Among the information, si_code is
supposed to have "SI_SIGIO" if the signal was generated by a queued SIGIO.
Instead of having SI_SIGIO (supposed to be -5) I get a value of 1. I also tried
"kill -s SIGIO <pid of server>" and got a value of 0 (SI_USER), which is the
expected value when the signal is raised by kill.
I'm currently using glib version 2.7-2 on Linux version 126.96.36.199-42.fc8.
To reproduce the problem simply setup a socket using fcntl (as above), make it
listen for incoming connections, and use sigaction (as above) to make a function
handle the signal. Inside the function, print out the contents of si_code. If
necessary, I can provide my own code.
Created attachment 2827 [details]
server code to see the problem
Created attachment 2828 [details]
client code to see the problem
I have added source code to reproduce the problem.
The server will never exit until killed by SIGTERM (or SIGKILL and SIGSTOP).
The client will just attempt to connect (to trigger the SIGIO signal) and then
Check this discussion, may be helpful
Thanks for the info.
Apparently it's been known since 2000 that si_code does not contain SI_SIGIO
(like the man pages say) anymore.
Looks like it will stay that way for a while now, so I'll just avoid using
si_code for now.
This is a bug in the manpages, I've brought this bug to the attention of the Linux man page maintainer.
Closing as INVALID since it's not a bug in the documentation that is part of glibc.