5:58 p.m.
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 :-(
2:49 a.m.
Gunnar Evermann wrote:
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.
yes, both functions need to be consistent and use the same method. please send
a patch.
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.
i'm not quite sure what you're saying here. have you tried commenting out the
slow_down_interrupts/speed_up_interrupts calls? does this fix all problems, or
is there something still wrong with interruption?
it's high time we ifdef those slow-down calls with ULTRIX or something.
Gunnar
P.S.: This is mostly a repost of
http://list-archive.xemacs.org/xemacs-beta/200011/msg00035.html
to which nobody replied :-(
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
1:30 p.m.
Ben Wing <ben(a)666.com> writes:
Gunnar Evermann wrote:
> 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.
i'm not quite sure what you're saying here. have you tried commenting out the
slow_down_interrupts/speed_up_interrupts calls? does this fix all problems, or
is there something still wrong with interruption?
Yes I have but only on Linux 2.2/glibc2.2 so far. I am worried that
this might break on random system.
it's high time we ifdef those slow-down calls with ULTRIX or
something.
If it is really only ULTRIX. There is also a comment referring to
"some kernels", whatever that means.
I will test removing the slow_down_interrupts/speed_up_interrupts on
some more platforms I have access to and then apply a patch to the
trunk. We should then encourage people to test this in the next beta.
Martin (or anybody else), maybe you could also try this on your
amazing collection of random machines :-) Please try the following:
- apply the sysdep.c patch
- start xemacs -vanilla and eval
(open-network-stream "bug" nil "10.0.0.42" 42)
- press some random keys (to cause SIGIOs and see whether connect
survies restarting)
- try to interrupt with C-g
- wait for upto 15 secs and see whether C-g worked
- now apply the process-unix.c patch and try again.
If C-g doesn't work after applying the patches then the output of
strace/truss might be useful.
thanks in advance!
Gunnar
P.S.: Of course we should also fix x_check_for_quit_char(). I will send a
separate message about that.
Index: sysdep.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.c,v
retrieving revision 1.38
diff -u -r1.38 sysdep.c
--- sysdep.c 2001/04/12 18:24:22 1.38
+++ sysdep.c 2001/04/16 12:20:17
＠＠ -1108,7 +1108,7 ＠＠
{
int filedesc = DEVICE_INFD (d);
-#if defined (I_SETSIG) && !defined(HPUX10)
+#if defined (I_SETSIG) && !defined(HPUX10) && !defined(LINUX)
{
int events=0;
ioctl (filedesc, I_GETSIG, &events);
Index: process-unix.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/process-unix.c,v
retrieving revision 1.20
diff -u -r1.20 process-unix.c
--- process-unix.c 2001/04/12 18:24:11 1.20
+++ process-unix.c 2001/04/16 12:00:20
＠＠ -1721,8 +1721,9 ＠＠
/* Slow down polling. Some kernels have a bug which causes retrying
connect to fail after a connect. */
+#if 0
slow_down_interrupts ();
-
+#endif
loop:
/* A system call interrupted with a SIGALRM or SIGIO comes back
＠＠ -1730,7 +1731,9 ＠＠
SETJMP (break_system_call_jump);
if (QUITP)
{
+#if 0
speed_up_interrupts ();
+#endif
REALLY_QUIT;
/* In case something really weird happens ... */
slow_down_interrupts ();
＠＠ -1764,9 +1767,11 ＠＠
failed_connect = 1;
close (s);
+ s = -1;
+#if 0
speed_up_interrupts ();
-
+#endif
continue;
}
＠＠ -1791,7 +1796,9 ＠＠
break;
} /* address loop */
+#if 0
speed_up_interrupts ();
+#endif
freeaddrinfo (res);
if (s < 0)
＠＠ -1852,7 +1859,9 ＠＠
/* Slow down polling. Some kernels have a bug which causes retrying
connect to fail after a connect. */
+#if 0
slow_down_interrupts ();
+#endif
loop:
＠＠ -1861,7 +1870,9 ＠＠
SETJMP (break_system_call_jump);
if (QUITP)
{
+#if 0
speed_up_interrupts ();
+#endif
REALLY_QUIT;
/* In case something really weird happens ... */
slow_down_interrupts ();
＠＠ -1892,13 +1903,17 ＠＠
close (s);
+#if 0
speed_up_interrupts ();
+#endif
errno = xerrno;
report_file_error ("connection failed", list2 (host, name));
}
+#if 0
speed_up_interrupts ();
+#endif
#endif /* ! HAVE_GETADDRINFO */
}
8615
days inactive
8616
days old
2 comments
2 participants
participants (2)
-
Ben Wing -
Gunnar Evermann