From owner-freebsd-mozilla Tue Sep 14 16:45: 8 1999 Delivered-To: freebsd-mozilla@freebsd.org Received: from sparkle.Generation.NET (sparkle.Generation.NET [205.205.119.4]) by hub.freebsd.org (Postfix) with ESMTP id 6BD9114D51 for ; Tue, 14 Sep 1999 16:45:00 -0700 (PDT) (envelope-from gsstark@mit.edu) Received: from localhost (brnstndkramden.acf.nyu.edu@x2-513.mtl.Generation.NET [209.205.11.168]) by sparkle.Generation.NET (8.9.3/8.9.3) with SMTP id TAA22587; Tue, 14 Sep 1999 19:45:07 -0400 (EDT) To: Terry Lambert References: 199905030116.saa1670-@usr05.primenet.com Subject: Re: Communicator 4.5: "Xlib: Unexpected async reply" msg flood! Cc: denis@acacia.cts.ucla.edu (Denis DeLaRoca) Cc: mozilla@freebsd.org From: Greg Stark Date: 14 Sep 1999 19:44:53 -0400 Message-ID: <87vh9df47e.fsf@mit.edu> Lines: 50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-mozilla@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't think this explanation really makes sense. Netscape doesn't actually use the native threads, it uses some sort of user-space threads on all platforms. It is the right basic idea though, "Unexpected async reply" and the "sequence lost" both have to do with either a multi-threaded program calling Xlib functions from two threads or a signal handler calling Xlib functions. Do you have further evidence about this involving freebsd native threads? greg > > I've seen this problem occur with both the FreeBSD version of Communicator > > 4.5 in the packages collection as well as with Communicator 4.51 for Linux > > under FreeBSD 3.1. > > ... > > Communicator starts looping and outputting messages to stderr that read > > > > Xlib: Unexpected async reply (sequence 0x####) > > I believe the dialog box you refer to runs as JavaScript. > > There are a number of problems with the FreeBSD implementation of > Netscape. > > The number one problem is that it is assuming that threads serially > run to completion based on scheduling. > > Basically, this means that if you get an involuntary context switch, > the threads pick up where they left off, in the order that they > left off. > > The FreeBSD threads don't guarantee this (neither does POSIX), so > the serialization assumption is flawed. > > For what it's worth, Linux and Macintosh threading have the same > issues with the assumptions made by the NetScape JavaScript engine > programmers. > > The major problems most commonly surface in the builtins, like the > bookmark change script, the mail client, and the GIF decoder. The > workaround for GIF's is to serialize the GIF loading (easy; just change > your JavaScript) or to replace the GIF loader with a JNI to some > reentrant code (not very easy, and not very portable; it'll only > fix your personal browser). > > Since the problem exists on other platforms (e.g. Macintosh), it's > best to just let it do its thing and finish doing it, before you > move the mouse pointer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mozilla" in the body of the message