In defense of Firefox

Agreed. It should really be multithreaded.

The threading isn't actually the whole of the problem.

When fsync() is called on certain filesystems (ext3 without certain optimizations turned on is
mentioned in the bug) it causes the whole desktop to freeze/slow as all the data is written to
disk.

fsync() in these filesystems is really just a call to sync(). :-(

Ciao!

In my experience, UIs are always required to be single-threaded. The locking needed to make
multi-threaded UIs work will tend to kill any speed advantage. Now some time-consuming
operations maybe ought to be done asynchronously so the UI thread doesn't have to wait for
them. But that's easier said than done. I suspect that the problem you're seeing (and which I
recognise) is due to running Javascript in the UI thread. I don't know whether it's possible
to avoid that, without introducing potential for deadlocks.

> There's no reason whatsoever that tab1 needs to not render or
> respond because tab2 is doing something or other.

The reason is the ancient design decision that the UI and behavior would be customizable
through JavaScript extensions. As extensions are global (i.e. they can see and manipulate all
of your tabs and UI elements), they need to live in a single interpreter.

JavaScript has classically been a single-threaded language; making it multi-threaded now would
create a lot of confusion and unexpected race conditions; most developers cannot even begin to
imagine all the ways that, for example, the renderer and concurrent changes to a document's
DOM could interact.

Adding coarse-grained locking does not have much benefit: any interaction between concurrent
threads would still likely cause one to wait for the other to yield a lock. On the other hand,
with fine-grained locking, writing code to handle race conditions would make extensions and
Firefox more complex and more error-prone.

Furthermore, adding concurrent multithreading support to a high-level language is no easy task
and has a significant performance impact on the interpreter alone -- as Perl, Python, Ruby,
Smalltalk etc developers can confirm.

Now, I'm just playing the devil's advocate and pointing out all the problems with this
approach; clearly it is *possible* to rewrite Firefox as a multi-threaded browser, but it's a
decision that has to be made with great precaution.

I agree that this is an important issue: I switched to Opera for this reason.
And I doubt that FF3 will make me switch back as the 'one tab freeze the whole browser' issue
will still probably be there.

I believe you have to have some other process(es) with heavy disk I/O, so when ff3 fsync()s,
it also fsync()s all disk I/O, not just its own.  I have had it when surfing while a compile
is running, and it is awful.

> I'm using Fedora 9 at home and have yet to encounter this behavior. What does it take to
trigger it?

The issue is that Firefox will perform large numbers of fsync system calls on files in
~/.mozilla, and fsync is implemented as a global sync on journaled filesystems.

One way to reproduce the slowdown is to put ~/.mozilla on an ext3 filesystem which has heavy
unrelated write traffic.  Another is to put it on a busy NFS filesystem (having home on NFS is
rather common in academic settings).

There's a lot of satisfaction to be had in reflexively ranting about things and slamming on
them.  In my experience, there is ultimately more satisfaction -- just of a slower and less
instantly-gratifying sort -- in learning and building.  Unfortunately, the two approaches are
often at odds, because one is fundamentally about protecting one's preconceptions, while the
other requires with-holding judgement and seeking out ways to challenge them.  In this case,
you're being factually wrong, utterly ignorant of the relevant technical issues, and actively
hostile to changing either -- but you do probably *seem* smart to some readers, and that's a
choice you can make.  Many technical people do.  YMMV.

@jch: Please do some research before posting. SqlLite doesn't pretend to be an RDBMS. It
doesn't support (enforce) basic datatypes. The shared library is ~1MB on my system (and can go
down to ~100K when embedded and features removed).

Yes, it supports "strong integrity guarantees". The opposite of that is called "corruption".
If you wrote a browser, would you just call "truncate(bookmarks); write(bookmarks, data);
close()"? I hope not. You would need to design a fail-safe recovery mechanism that doesn't
loose data. It might be fairly simple when updating bookmarks, but for storing browsing
history and doing indexing, you'd basically be re-writing most of SqlLite anyway.