Re: Gnome/Gtk and thread safety

["Dan Maas" <dmaas dcine com>]

> I tend to think of resource acquisition as a more useful model
> for thinking about large programs than state, because it focuses on
> the stuff important to one particular area of code

OK, I'll grant you that's a valid statement, even though I don't personally
feel this way. IMHO by the time you get to thinking about resource
contention and acquisition, you're already in the realm of very heavy-duty
concurrent systems (kernels and database servers). If you're working on a
high-performance database, by all means use all the threading you want. But
none of this is really necessary for simple GUI clients. If your Gtk app is
spending lots of time doing number-crunching or disk I/O, then I'd suggest
reworking it into a client-server system. I'd say most - perhaps not all,
but most - GUI apps can be decomposed into a heavy-duty backend which
communicates over the network to a thin Gtk shell. Unless you absolutely
must share lots of data between the two, multithreading the client is not
really called for.

> If you ever succumb to the temptation to invoke the event loop in the
> middle of some other operation in async code, you are pretty doomed

Agree 100%. There should only be one line of code in your entire program
that can block / dispatch events. Keep state explicitly in a data structure,
not on the call stack =). (I bet there's even a mechanical algorithm one
could use to transform code that calls the event loop into code that saves
state, drops back into the main loop, and recovers after a subsequent
event...)

> use of
> libraries that don't provide an async interface.

Libraries that don't provide an async interface should be blindfolded, lined
up, and shot.

(that reminds me -- has anyone been working on async CORBA for gnome? I'd
hate to see people spawning threads here and there just because basic CORBA
is broken =)

> I can't see how a shared media server would work better than loading
> images off of local disk.

Say I'm working on my website. I have the html open in Emacs, an image open
in the Gimp, and Mozilla up to preview the result. I paint a new stroke on
the image. Why doesn't Mozilla show it right away? I type some more html
code in Emacs. Why isn't the display updating, dammit?! All current systems
have this shortcoming because they only make use of the filesystem, which
cannot relay change notifications or updates. I am working on a system that
conquers this problem by using "live" data buffers maintained in, and
broadcast from, a server process.

Regards,
Dan