Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Elliot Lee <sopwith redhat com> writes:

> On 3 Oct 2000, Maciej Stachowiak wrote:
> 
> I agree that having to worry about reentrancy is a pain, but the problem
> is that ORBit2 uses the glib main loop implicitly, and lots of people have
> wanted things to work this way for a while. Even if you are just using
> gtk+, you have to occasionally worry about reentrancy, and stuff that uses
> CORBA already has to worry about it a lot.
>

I don't think that's necessarily a good design. The people who think
they want things to work this way are wrong - they don't know just how
much of a pain it is to make your app fully re-entrant.

I bet you very few (none?) of the apps out there, ones that call the
event loop included, will deal properly with something like having
their main window closed while doing an event loop 20 frames down the
call stack. Basically every function in your program would have to
either ref objects it wants to hold references to across a call to any
function that _might_ call a CORBA method, or connect to their destroy
signals to make sure not to operate them (since there is no safe way I
know of to look an obect reference and tell if it's dead); and a
similar solution for anything dynamically allocated that is not a
GtkObject. I have never seen code that actually does this anywhere.

I put in calls to the event loop in a bunch of places in Nautilus and
I thought it was safe, but it later turned out to cause really weird
crashes, so now I'm painstakingly backing it all out.

Take it from someone who has been burned, if you call the event loop
it's practically certain your app will crash when things happen is a
surprising order.

> In other words, the app already will to deal with this somewhat. I think
> it would be worth trying the glib main loop approach out to see if it
> works right now.
>

I definitely don't think it's the best approach for the GNOME 1.x
ORBit, even if it somehow works well for ORBit 2, lots of apps that
don't expect this behavior will break.

> I do not like Mathieu's solution - for the long-term we won't need this
> change anyways. If the glib main loop solution is proven to not work
> short-term (for GNOME 1.4), then perhaps OAF can be branched for 1.4 and
> an OAF-internal version of Mathieu's solution (no exposure of asynchronity
> to the app, just run glib main loop while waiting for callback) can be
> implemented there.

Why do you think exposing an async API is so bad? If ORBit 2 somehow
solves all these problems for GNOME 2 (or later), we can remove these
calls.

The app we mainly want this for, Nautilus, definitely would prefer an
async API to invoking the main loop, since invoking the main loop has
badly broken it before. Explicit asynchronicity is much _much_ easier
to deal with than calling the main loop.

- Maciej

P.S. to Mathieu: I forgot to mention one thing your API needs which is
a way to cancel an activate_async call (the CORBA level does not
necessarily need cancellation, but at minimum the client library
should not call the callback - this is the other advantage of explicit
async, the ability to cancel and not have to deal with a callback that
needs to sanity check everything.