Regarding: SIGALRM used for SMART_SCHEDULE interacts badly with system calls Email: [EMAIL PROTECTED] ------------------------------------------------------------ XFree86 Version: XFree86 Version 4.2.1 / X Window System
OS: FreeBSD 4.4-RELEASE-p1 i386 [ELF] Area: Xserver Server: XFree86 (The XFree86 4.x server) Video Card: It does not have to do with the video card. Description: The server compiled with SMART_SCHEDULE arranges for a SIGALRM to occur every 20ms. This very frequent signal interacts badly with the rest of the system calls performed by the server. In particular, when using modules/wacom_drv.o with the serial tablet NOT plugged in, I found that although the server starts up OK, later if an application such as GIMP is started that attempts to access the tablet, the X server hangs in a tight loop involving repeated calls to select() that are interrupted by SIGALRM and then retried. This is because the calls to select() in xf86OpenSerial() are wrapped in a SYSCALL macro that retries the select() until EINTR is not returned. However, any call to select() that waits longer than 20ms is guaranteed to be interrupted by SIGALRM, so the loop never terminates. This is not a problem during the initial server startup, because the SMART_SCHEDULE alarm signals are apparently not started until after this phase. Also, FreeBSD does NOT update the timeval argument to select() as Linux does when the call to select() is interrupted. It is probably inadvisable for the X server to rely on this semantics, as it seems to be non-POSIX and there is little agreement that the Linux behavior is better. In any case, the problem is not limited to select(). After rewriting the WACOM driver to avoid the calls to xf86WaitForInput() that were hanging, I found that a similar problem still occurs in xf86OpenSerial(), with the call to open(). On FreeBSD, it is possible for a call to open() on a serial port to block for several seconds while waiting while the driver is holding DTR low. Again, the open() call is repeatedly interrupted by the SIGALRM, and then it is retried. This apparently continues the DTR low condition in the driver for an indefinite period. I don't think this is really a problem with FreeBSD. It is really a problem resulting from the use of rapid periodic signals, together with the way all the system calls in the X server are wrapped in a SYSCALL macro that generates massive number of places where infinite loops can potentially occur. Repeat By: _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
