Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Elliot Lee <sopwith redhat com> writes:

> On 3 Oct 2000, Mathieu Lacage wrote:
> 
> > > I do not think this makes long-term sense in OAF, especially if you are
> > > just trying to get a tiny gain in GUI responsiveness during CORBA
> > 
> > This is not a "tiny gain". Activating mozilla takes 5 to 10 seconds on
> > my machine which is a PIII 700 MHz...
> 
> That is because mozilla sucks. Go fix mozilla :)

This is much more complicated than adding the relevant API to OAF
(which is 8 lines of IDL changes and 8 lines of header changes or
so). However, note that when OAF supports activation over the network,
the startup delay could be really long through no particular
programming fault, and the asynchronicity will be absolutely critical
here.

> > The UI is blocked for almost 4 to 7 seconds which is unaceptable.
> > Also, nautilus on startup spends a lot of its time in there and the
> > time for the display of the first window is directly related to this.
> 
> I think a simpler fix would just be to get glib loop iterations made while
> ORBit is inside an operation invocation. It should be about a one-line
> patch to get this in. It should accomplish the desired effect without
> having to complicate OAF.

Actually, calling an inferior event loop while you are in the middle
of something is _extremely_ dangerous. The context you return to could
have been completely invalidated by random user operations. This way
you would need to be _extremely_ paranoid and check objects for
validity, re-check assertions, etc or you will get mysterious crashes.

In fact, you already have to sort of be this paranoid about anything
that may have been changed by a CORBA call into the app. Making apps
have to account for any operation that could be spawned by the event
loop every time they make a CORBA call will make programming waaaaay
more complicated.

A traditional async callback approach is _much_ simpler for an app to
deal with.

> If the program being activated takes way too long to load, you are going
> to start getting timeouts inside OAF anyways (to handle stuck programs).

One reason why fixed timeouts are a bad idea. :-(

 - Maciej