Re: oaf async activation

[Torsten Schulz <Torsten Schulz germany sun com>]

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

    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.

    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.

    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.

    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.

-- 
Best regards,
 Torsten                            mailto:Torsten Schulz germany sun com