Re: oaf async activation

[Dan Winship <danw helixcode com>]

> Long-term, Nautilus will use threads throughought to resolve these
> kinds of issues (although of course it's tricky when dealing with
> non-thread-safe libs like ORBit, or "one thread at a time" libs like
> Gtk+). We plan to start moving away from the async architecture post
> 1.0.

Oh?

> I suspect Evolution is also moving in that direction, despite starting
> out with a "threads behind an async interface" model for gnome-vfs.

Actually, we made evolution-mail be threaded only because we decided
it would take much less time than rewriting Camel to have asynchronous
interfaces. Switching to threads caused us lots of pain and made the
internals of evolution-mail much more confusing, particularly due to
the not-especially-thread-safe nature of Gtk itself (and the fact that
we didn't want to rewrite Camel to be 100% thread safe either), so
there end up being certain operations that must happen in one thread,
and other operations that must happen in the other, and when you have
things like folders signalling that they have new messages, the Camel
thread has to hand off the signal to the UI thread, because you can't
call Gtk functions from the Camel thread.

We've talked about doing "Camel 2.0" with async interfaces some time
after Evolution 1.0, and then getting rid of threads in
evolution-mail.

> We didn't use threads for the first cut because some key GNOME
> developers convinced the Nautilus team at the time that threads were
> broken, unportable, hard to work with, etc.

Threads themselves aren't that broken, but gdb often doesn't cope with
them well. We've gotten a lot of totally useless stack traces from
people since we threaded evolution-mail (because they send a stack
trace from the wrong thread). Also, the gnome-segv hack seems to lose
in multi-threaded programs.

As for "hard to work with", Gtk and threads don't play well together.
If Gnome is going to embrace threads, Gtk and glib need to first.

> From what I have seen, async is even harder to work with (and
> definitely harder to get right!) than threads

Wow. We came to exactly the opposite conclusion. :-/

-- Dan