Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Torsten Schulz <Torsten Schulz germany sun com> writes:

>     I totally agree with Maciej because StarOffice ran in the same
> problems when we tried to solve UI blocking with calling the event
> loop while waiting for I/O operations. This approach causes similar
> problems as using threads in a non thread safe environment. As soon as
> multiple points of the source code call the event loop, anything can
> happen on your call stack - and for sure, surprising things will
> happen.

Well, I'm glad it's not just me. :-)
 
>     But if decide to add asynchronous methods to oaf, you will come
> to a similar discussion about other APIs like persistent, moniker
> resolution,... And you will end up with many interfaces, which are
> blown up with asynchronous methods.

Yes, I already did a gross hack in Nautilus to work around the fact
that the PersistStream, PersistFile and ProgressiveDataSink interfaces
are all synch, and potentially slow (espeically the first two). The
Bonobo maintainers seemed highly disinterested in having a fix for
this in Bonobo, and the Evolution hackers told me they didn't care if
the Evolution UI got blocked by these kinds of problems. (In case you
care, my solution was to have a separate process to handle these kinds
of components; the native Nautilus::View interface is all async-safe,
so it can be handled by Nautilus directly. See
nautilus/src/components/adapter for details).

>     Have you thought about the possibility to use threads on the
> client side to de-couple time consuming operations from the UI event
> loop? This will let the API clear and lean and the client will be
> forced to think about things like locking and synchronization. A bit
> more work to do on the client application, but it will keep the chance
> to solve all problems, just like the asynchronous approach.

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.

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

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.

But beyond what Nautilus and Evolution use, though, there is a bigger,
GNOME-wide architectural question to ask here: are we going to support
threaded architecture, async architecture, or both, with the GNOME
development platform.?

The logical conclusion of supporting async architecture is adding
async versions of any call that does something potentially slow, if
apps want to be truly non-blocking. That bloats the API a fair
bit. However, many in the GNOME community still have concerns about
the portability of threads and their accessibility to the average
developer.

>From what I have seen, async is even harder to work with (and
definitely harder to get right!) than threads, but others may not
agree, and it's true that each approach has it's advantages.

Perhaps we should start a conversation on this topic on gnome-hackers.

>     As I know ORBit is not thread-safe in the sense, that multiple
> threads can simultaneously send remote CORBA calls. The above
> suggestion will require such a functionality and I think it is
> possible to extend ORBit in this way.

I think ORBit2 will be thread safe.

 - Maciej