Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Dan Winship <danw helixcode com> writes:

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

Both gnome-vfs and the planned Camel 2.0 will have this problem from
what I can tell.

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

Gnome isn't doing so well at embracing async either. It seems like
right now, Gnome embraces your choice of blocking UI or building
massive kludge towers. :-)

In any case, it's pretty clear to me that not supporting threading at
all is not viable in the long run, because it's simply the way most
serious GUI applications are written. Supporting async as well is
certainly an option, albeit one that will likely bloat .idl and .h
files everywhere.

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

I am not convinced you gave both approaches a serious try. I'm more
inclined to consider the judgement of experienced people like Torsten
Schulz and Pavel Cisler who have many years of experience working with
different application architectures and shipping product based on
them. 

I was very nervous about threads at first (particularly since I don't
have any real experience with them and am not so good at the
concepts), but from what I can tell, async gives you many of the same
problems, only with worse-organized code and fewer tools to deal with
them.

 - Maciej