--yphFwFfvvckiOye+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 20, 2004 at 11:57:48AM -0800, Wolfgang S. Rupprecht wrote:
> Sometimes mozilla can be tricked into updating the statusbar to say
> what it is hanging on.  (click the stop icon, go into the URL window,
> hit <CR>).  When I did that just now mozilla-gtk says:
>=20
>      Resolving Host www.BIGCOMPANY.com...
>=20
> Now I can resolve the same FQDN from an xterm using host(), so it
> isn't like my local named doesn't have, or can't get the information.

This has been a problem for a LONG time on NetBSD. Based on purely
circumstantial evidence, it's related to Mozilla-derived (and
Netscape) applications using a helper application for DNS resolution
(kill -9 that, and your browser comes back much more promptly; not
that does any good for loading the page).

On Fri, Feb 20, 2004 at 10:18:09PM +0000, Christos Zoulas wrote:
> They are expected to blow up. If a threaded program needs to call
> a non-reentrant API it needs to make sure that it does not re-enter
> it by protecting it with a mutex.

It's worth checking, but my user experience is frequently similar to
Wolfgang, and it smells like Mozilla's calling non-reentrant code
without protecting it with a mutex.

How is Mozilla-on-Linux (or just plain Linux) cheating to make this
not happen there?

Filing bugs on Mozilla is, of course, like screaming into the
void...

--=20
gabriel rosenkoetter
gr@eclipsed.net

--yphFwFfvvckiOye+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFANtsk9ehacAz5CRoRApNPAJ4hsnDfxukBC3egUmr/SxJH+48WiwCdHA9I
YqwOZKzF6p9PbHNdjUB2dGo=
=QdMJ
-----END PGP SIGNATURE-----

--yphFwFfvvckiOye+--