Re: Gnome/Gtk and thread safety

["Dan Maas" <dmaas dcine com>]

> I think resource acquisition is simpler to think about than global
> program state. It also lets you deal with problems locally; async
> architecture based prgrams tend to be fragile and hard to get good
> performance out of because the event loop is a single point of failure
> for both stability and performance.

It can go both ways. Take a look at this paper by Gribble at UC Berkeley:
http://www.cs.berkeley.edu/~gribble/thread_vs_event/benchmarks.html

Basically he tried using an asynchronous model in Java, which heavily favors
blocking, multithreaded I/O. The async approach scaled much better.

On a single-CPU system you're already behind due to locking overhead (well,
assuming you stay away from disk i/o and CORBA =) ). On a multi-processor,
you have to be careful with operations that affect the memory map -- doing a
dlopen() or a mmap() or brk() from one thread will cause stalls while the
CPU caches are re-synched. (this is a major benefit of multi-process
approaches -- if you can cope with the extra context switch overhead, you
may very well end up faster since the VM is separate...)

As far as code management; well, I have to admit being something of a
microkernel person =). I believe in keeping functional modules separate,
using address space boundaries if possible. I just don't feel comfortable
with the concept of a monolithic process handling all sorts of I/O and
computation across lots of threads; there is just too much shared data. e.g.
If your database module is too slow, fork off a few independent database
server processes; they'll still be scheduled independently, and you could
very well gain stability due to the OS-enforced address-space separation.
(okay, so most microkernel-like systems end up drowning in context-switch
overhead... design your protocols carefully - no willy-nilly RPC
invocations - and buy fast hardware...)

> Let me cite an example: a file manager that aims to provide access to
> all of the modern features expected in a modern system, including:

You devil! =) Yeah, a file manager is going to be a doozy. Consider that the
Unix disk API's haven't changed since the late 70's; they just aren't
designed to handle nonblocking, interactive programs =). I do, however,
claim that a client-server system would be possible. Basically the features
you described all boil down to nearly the same thing - performing nasty disk
i/o or searching at the server, then shoveling the results over the network
to a small GUI client.

Local networking ain't terribly slow; it's quite feasible to run 50MB/sec
over a pipe or socket. Browsing a huge directory could be done incrementally
too - there's really not much data that needs to go across the network. Say
200 bytes/file * 10,000 files = 2 MB, which could be passed in a few tens of
miliseconds if the data is all there ready to go... Latency is the only real
issue; you have to make sure the server checks for new requests frequently
enough, and gets enough chances to schedule.

I moved the rest of my reply off-line as it has little to do with gtk...

Dan