From owner-freebsd-hackers Wed Nov 8 10:22:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13133 for hackers-outgoing; Wed, 8 Nov 1995 10:22:43 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13128 for ; Wed, 8 Nov 1995 10:22:39 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA20449; Wed, 8 Nov 1995 11:17:29 -0700 From: Terry Lambert Message-Id: <199511081817.LAA20449@phaeton.artisoft.com> Subject: Re: Timing bug with Netscape 2.0b2 To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 8 Nov 1995 11:17:28 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.org, jehamby@lightside.com, x_cbug@netscape.com In-Reply-To: <3348.815811591@time.cdrom.com> from "Jordan K. Hubbard" at Nov 7, 95 10:19:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3298 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Look at the state of system call restart after SIGALRM on setitimer() > > for BSDI vs. FreeBSD in BSDI compatability mode. > > If they're using setitimer() instead of a timeout to select(), that'd > be unbelievably mutant. What makes you think they're doing it that > way? strace > Signal handling in X applications is something to be avoided, > not embraced. I've done "blinking" just fine with the supplied > (non-signal using) timers in other applications. "Blinking" is done with the select() timer. Other crap is done with the itimer. The itimer fires of at a high multiple of the select timer timeout duration. I imagine the reason the do this is because they want a standard timing invariant under large amounts of X events for animation. Like the little Meteor'ed 'N' that is updated at a high multiple of the Motif XmText fields InsertionPoint blink rate. I've used a similar technique for animation in X games, though I went through the code carefully and gauged the loop timer in the animation path and outside the animation path and unrolled XtMainAppLoop() myself, wirining my select() timeout that way. Since they use the standard Motif library, I'd say that the reason they do it is because they have very little leeway in implementing what they want to implement otherwise. If you don't unroll the whole code path or use a path shortened or preemptible Motif implementation, you're pretty much guaranteed that the Motif event processing will take longer than your timer period in some cases and make your animation jumpy. You could reduce this (but not eliminate it) by internally queueing callback actions to occur later, and then handling callbacks like X events and timeouts: from inside the main app loop. Depending on the speed of the machine you are on, this can result in a "jumpy" or "unresponsive" aplication, depending on how low level you code your callback intercept-and-queue. So really, they have little choice. Actually, FreeBSD's select() is broken: /* select is not restarted after signals... */ if (error == ERESTART) error = EINTR; (sys_generic.c) at least as far as BSDI compatability is concerned. As far as SunOS compatability is concerned, only the read/write/wait calls are not restarted unilaterrally, so the extended list in FreeBSD is broken as well (in SunOS, the default is restart). I think the SunOS sigaction(3 is improperly documented; I think any tsleep'er in fact gets restarted. The siginterrupt(3V) man page on SunOs makes this more apparent, implying it affects *all* system calls which may be alarmed out of. SVR4 actually has an "interruptable" flags bit in the sysent[] table that tags the affected function. > [Note: We should probably take x_cbug out of the Cc line if this is > going to turn into a debate! :)] Actually, NetScape should be made aware of the issues with regard to *at least* setting the signals away from the system defaults to known defaults, and should be aware that FreeBSD incorrectly handles select(2) restart (so their timer fails). The question is whether you can claim binary compatability with BSDI without fixing select(2), etc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.