HELP! [un]request_sigio_on_device() fubar'd on Linux
I could really use some advice from people who know a bit about Unix
APIs and Linux in particular (Martin? Jan? Ben?). Sorry for the
long-winded explanation, please bear with me.
The unrequest_sigio_on_device function is completely broken on Linux
AFAICT.
We have the following in sysdep.c:
----------------------------------------------------------------------
request_sigio_on_device (struct device *d)
{
int filedesc = DEVICE_INFD (d);
#if defined (I_SETSIG) && !defined(HPUX10) && !defined(LINUX)
{
int events=0;
ioctl (filedesc, I_GETSIG, &events);
ioctl (filedesc, I_SETSIG, events | S_INPUT);
}
#elif defined (FASYNC)
fcntl (filedesc, F_SETFL, fcntl (filedesc, F_GETFL, 0) | FASYNC);
[...]
unrequest_sigio_on_device (struct device *d)
{
int filedesc = DEVICE_INFD (d);
#if defined (I_SETSIG) && !defined(HPUX10)
{
int events=0;
ioctl (filedesc, I_GETSIG, &events);
ioctl (filedesc, I_SETSIG, events & ~S_INPUT);
}
#elif defined (FASYNC)
fcntl (filedesc, F_SETFL, fcntl (filedesc, F_GETFL, 0) & ~FASYNC);
----------------------------------------------------------------------
On Linux (on most variants I have seen) both I_SETSIG and FASYNC are
defined. Thus in request_sigio() we use the ioctl and in
unrequest_sigio() we use the fcntl. Surely, this is wrong?
I think Jan had a patch for 21.1 that added the !defined(LINUX) to
unrequest_sigio as well, so that we used fcntl in both cases. This
might be a good thing, since when we use the ioctl what actually
happens (according to strace) is:
ioctl(6, CDROMVOLCTRL, 0xbfffea84) = -1 EINVAL (Invalid argument)
ioctl(6, CDROMEJECT, 0) = -1 EINVAL (Invalid argument)
this is clearly rubbish. (Aside: shouldn't we check the return value of
ioctl() anyway?). So, what happens in the current code is that we never
manage to disable SIGIOs.
OK, so when I "fix" this (causing fcntl to be used in both cases)
another problems surfaces. The code that tries to check for C-g to
interrupt system-calls fails under X (I tried to debug
x_check_for_quit_char() but C-g never appeared in the X event queue --
no idea why). The result is that things like
(open-network-stream "bug" nil "10.0.0.42" 42)
cannot be interrupted and will hang xemacs permanently (this was
pointed out by Simon Josefsson last year and is IMHO the major bug in
21.1).
Why do we need to wrap the connect() call inside open-network-stream
in slow_down_interrupts/speed_up_interrupts anyway? The current code
where SIGIOs get delivered and interrupt connect() seems to work fine.
Any help with this is very much appreciated.
Gunnar
P.S.: This is mostly a repost of
http://list-archive.xemacs.org/xemacs-beta/200011/msg00035.html
to which nobody replied :-(