Date: Wed, 8 Nov 1995 11:17:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, hackers@FreeBSD.org, jehamby@lightside.com, x_cbug@netscape.com Subject: Re: Timing bug with Netscape 2.0b2 Message-ID: <199511081817.LAA20449@phaeton.artisoft.com> In-Reply-To: <3348.815811591@time.cdrom.com> from "Jordan K. Hubbard" at Nov 7, 95 10:19:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511081817.LAA20449>