Re: Notes from meeting at Red Hat, 31 Aug 2001

[Maciej Stachowiak <mjs noisehavoc org>]

On 06Sep2001 10:18PM (-0400), Owen Taylor wrote:
> 
> Michael came by Red Hat last Friday; we had a useful discussion about
> various aspects of the devel platform and about getting GNOME 2.0
> out. The following is an edited writeup of notes I took during the
> meeting, with additions from Michael.
> 

Hey guys, 

Sounds like a very fruitful discussion to me. I have a couple of small
comments.

> For reentrancy, discussed solutions included:

CORBA re-entrancy is a pet issue of mine since I've been shot in the
foot by it a couple of times in Nautilus.

>  - Not allowing reentrancy at all, going to threading. Michael was
>    strongly of the opinion that this would just substitute deadlocks
>    for unexpected reentrancy.

It seems like avoiding the deadlocks is not that much harder than
avoiding unexpected reentrancy. You could set a rule like: 

* a thread must not hold any locks that may be needed by any incoming
two-way CORBA call across an outgoing two-way CORBA call

This is a somewhat restrictive rule, but has the advantage of making
all possible resource contention explicit. 

Impact on apps could be reduced in some cases by requiring that
implementations of particular IDL methods not make any outgoing
two-way calls, or only make outgoing two-way calls only on a specific
pre-defined set of objects (the set could be a combination of things
like objects passed to the call as arguments, the ControlFrame
associated with a Control, and system-wide out-of-proc services like
gconf/bonobo-conf).

I think many of the standard Bonobo IDL methods could reasonably make
guarantees like this.

(As my rules above hint, one-way calls are less of a problem because
they don't block the caller; perhaps we should strive to make any call
that has no return value and no exceptions a oneway call).

I think it's useful to address things at this level even if we have a
way to turn off re-entrancy, since sometimes you really need to accept
incoming calls but need tools to control the concurrency/re-entrancy
issues.


>  - Adding hooks in the ORB for controlling reentrancy. [With ORBit2
>    it should be possible to do things like:
> 
>     orbit_invoke_nonreentrant (object, "foo", ..., &result);
> 
>    though there would clearly be a performance hit.]
> 
>    GConf is probably the most pressing problem as far as reentrancy is concerned
>    since it doesn't look like involves remote/reentrant calls but actually 
>    involves such. It probably is possible to control reentrancy from
>    GConf in the short term by using one-way methods and by doing some sort of POA-wide 
>    or global stop_taking_connections() / start_taking_connections() call around outgoing
>    calls.

It might be nice to have a global call for this, but there'd need to
be a way to temporarily override the setting for the current thread
only (so unsuspecting outgoing calls on other threads are not affected
if your app is multithreaded).

>  - In-process components should be used when at all possible, since they
>    mostly avoid reentrancy and life-cycle issues. 

I'm not sure it entirely solves the re-entrancy issue - you can
perhaps block CORBA calls from outgoing processes, but the in-proc
component might itself make CORBA calls back to the app in the middle
of processing an incoming call. Isn't that basically just as bad as
getting a random unexpected CORBA call?

Of course, this is not so much a CORBA issue as it is a "dynamically
loaded code that might make arbitrary calls back into your app" issue.

It's really only safe if the in-proc component is one you know about
and can evaluate for potential bad interactions.

> 
>  - Widgets as small as the Nautilus throbber should _not_ be Bonobo components.
> 

I thought if you are using the Bonobo UI handler for a particular
toolbar, any widgets you put in the toolbar must be bonobo components
(though not necessarily out-of-proc ones as the throbber is). Am I
wrong on this? I'd love to be. :-)

 - Maciej




_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers