Re: Gnome/Gtk and thread safety

[Maciej Stachowiak <mjs eazel com>]

"Dan Maas" <dmaas dcine com> writes:

> > 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. 

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.

> 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.

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:

* Ability to browse huge directories efficiently

* Ability to view search results (which might be huge) as a directory

* Transparent access to ftp, WebDAV, NFS, SMB and whatever other
  protocols users find useful.

A client/server implementation is simply going to be too slow to do
this well I think.
 
> > 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...)

Gtk+, of course, gives you all the tools you need to shoot yourself in
the foot with the gtk_main_* family of functions. ORBit does it for
you by dispatching CORBA calls while waiting for CORBA results (but to
be fair this is the only way to avoid deadlock short of using threads
or async interfaces, neither of which ORBit supports).

> > 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 =)

There was talk of it on gnome-components-list. Brief conclusions:

* Most Bonobo IDL is not async-safe

* CORBA has an async messaging spec, but ORBit does not implement it,
  and it sucks anyway

* We could hack up our own async thing by writing a special IDL
  compiler, but no one has done it yet

I think gnome-vfs is about the only major GNOME library that provides
async interfaces for everything, thanks to Ettore. OAF is also
relatively async-safe, dunno about other stuff.

So as a platform, GNOME does not support threads _or_ async very well
at all right now.
 
> > 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.

Ah, live updates. This sounds like a cool idea. Are you aware of SGI's
fam and imon projects for Linux, which provide file monitoring in a
generic way, not specific to "media"? It is used by efm and will be
used by a future version of Nautilus.

The one drawback to your approach is that you need a huge undo chain
that's persistent across app invocations if there is no explicit
"save" operation needed. I'd be happier seeing Mozilla update when you
save in the Gimp or Emacs.

 - Maciej