Re: oaf async activation

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel helixcode com> writes:

> 
> I dont think it was a lack of interest, but rather that no good
> solution was proposed.  Maybe i am wrong, but I am definetly
> interested in fixing this.
> 
> Do you have any suggestions for this?  We have until monday to change
> Bonobo :-)
> 

I think it's now too late to change something this majorly for Bonobo
1.0.

My proposal was to make the PersistStream, PersistFile and Stream
interfaces all oneway calls that take a callback object. I remember
many theoretical objections to this proposal (it might in theory never
deliver the oneway calls; it might in theory block anyway) but no real
ones (the Nautilus::View interface, which is oneway and callback based
never blocks the Nautilus UI, while the PersistStream interface
definitely does; and I've never seen it silently lose a oneway).

Note that it's necessary not to leave a synchronouse Stream interface
at the IDL level all, since that is what the the component being
loaded uses to talk to the app; if it could make long-running sync
calls, it could force the app to block. This makes life somewhat
harder for component authors who don't care about blocking, or who use
threads, but it's always possible to provide a sync-looking wrapper on
top of async IDL, as long as ORBit provides some way to wait for
incoming CORBA messages.

When I suggested this, I recall you in particular voicing all sorts of
strong objections to the whole concept, and in the end I gave up
before even posting IDL for this reason. (Interesting side note - you
suggested using ProgressiveDataSink instead, but it turns out that
even for the very few components that astually provide this interface,
it is not async-safe either).

Then it was announced that Bonobo wants to move to the OMG Stream
interface. I have no clue if that one is async-safe or not, but I
imagine not based on what usually comes out of the OMG.

> > 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.
> 
> I am still convinced about this myself.  We are using threads in
> Evolution as a stop gap measure, the Evolution team is interested in
> revamping Camel to have an async api and asyncronize the entire
> pipeline.  
> 

It's pretty interesting that the Evolution team found it easier to use
threads for the first cut, when many of the people in charge of
Evolution originally convinced the Nautilus team that an async
achitecture would be much easier.

However, that notwithstanding, if we want to really support async
architecture as a feasible way to do an app in GNOME, we'll have to
make sure all the Bonobo IDL which might trigger slow operations is
designed to be async-safe (and similarly for every GNOME API).

It's too bad I got discouraged from doing this for Bonobo 1.0 because
I have a fair bit of relevant experience now, from doing work to clean
up parts of Nautilus to be properly async, but I will probably be less
interested post-1.0 since Nautilus is moving to threads.

 - Maciej