Re: oaf async activation
- From: Maciej Stachowiak <mjs eazel com>
- To: otaylor redhat com
- Cc: Elliot Lee <sopwith redhat com>, Mathieu Lacage <mathieu eazel com>, gnome-components-list gnome org
- Subject: Re: oaf async activation
- Date: 03 Oct 2000 15:45:46 -0700
otaylor redhat com writes:
> Maciej Stachowiak <mjs eazel com> writes:
>
> > > 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.
>
> Note that ORBit allows incoming calls while waiting for
> an outgoing operation, so please take care of thinking about
> reentrancy when making outgoing calls in servers.
>
Which is pretty much what I said in my last paragraph. Of course, the
GUI parts of Bonobo make every app a server so you always need to be
paranoid, and you can't really use locking primitives because then you
could get deadlocks (presumably this is what the handling of incoming
calls while waiting for a response was meant to avoid). Having to
check the whole state of the world you care about on return from every
CORBA call is a huge burden, and I bet no app actually does this
properly (especially since incoming calls may have invalidated
GtkObjects at arbitrary points up the call stack from where you make
the outgoing call).
So basically this is a big mess.
- Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]