Date: Tue, 7 Nov 1995 22:53:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hackers@FreeBSD.org Cc: jehamby@lightside.com, x_cbug@netscape.com Subject: Re: Timing bug with Netscape 2.0b2 Message-ID: <199511080553.WAA19389@phaeton.artisoft.com> In-Reply-To: <2872.815806980@time.cdrom.com> from "Jordan K. Hubbard" at Nov 7, 95 09:03:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It isn't just blinking text (although if you want a cool example, try the > > Netscape Hall of Shame: http://www.meat.com/netscape_hos.html and click > > on "Blink Sink"). Another thing which is supposed to blink (but in > > FreeBSD does not) is the insertion point in the currently active > > TextField (for example, in the Location box at the top, or in a fill-out > > form). > > OK, I just verified this. You're right! > > I even know what's happening, though not exactly why. The event loop > select()'s on the X / network sockets and also sets a timeout (or > *should*) for processing any interval tasks, like blinking. > Apparently, it's not falling out of select on the timeout to the blink > task and it requires some other event on one of the selected fds > before the blink task can run. > > I actually kinda doubt that this is a FreeBSD specific problem. It's > more likely something in the Motif or Xt libraries they're using. I'd > lean towards Xt since that's where XtAppAddTimeout() lives, unless > Motif has added a wrapper function for this in 2.0. It could also be > an application side error in Netscape itself. Foo! Once again: Look at the state of system call restart after SIGALRM on setitimer() for BSDI vs. FreeBSD in BSDI compatability mode. If the select() is interrupted by the alarm, the select timeout never occurs. If it is restarted, then the timeout will occur as expected without interference by the interval timer. In "man 2 sigaction": If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). Add select(2) to the list of affected system calls, and set the SA_RESTART in sa_flags for the default for the BSDI execution class. 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?199511080553.WAA19389>