On Tue, 2002-05-14 at 18:04, Michael Meeks wrote:
> Hi Michael,
> 
> On Tue, 2002-05-14 at 01:26, Not Zed wrote:
> > They wont be able to do anythign about it anyway, so it doesn't matter. 
> > If they care enough they can use gdb manually.
> 
>       It's not possible to attach gdb to a process that lives for only a few
> handfuls of milliseconds, and dies without giving a user visible
> message. Bug buddy would help to get this error handled, that is unless
> you know something I don't.

gdb program-name


> > >   b) It looks like a CORBA method is being called from a 
> > >      class_init method, this has caused some serious grief in
> > >      Gnome 2.0, where re-enterancy is more likely due to a lot
> > >      less blocking going on.
> >
> > So you're saying the reentrancy problem isn't addressed and has gotten
> > worse?
> 
>       I'm saying that there are no more places where re-enterancy is
> theoreticaly possible, simply that it seems that fewer of these
> re-entered in Gnome 1.4 - for reasons unexplained. We really ought to
> add a 'manic re-entrancy' mode, where it attempts to allow methods to
> re-enter as much as possible for testing I suppose - fairly easy to do.
> 
>       ORBit2 does a lot less blocking, which gives better performance, but
> yes - one consequence of handling more CORBA calls more quickly is that
> you get more re-enterancy.
> 
> > What a total nightmare.
> 
>       Well - since evolution will be porting to Gnome 2.1, I have a couple of
> somewhat trivial ideas to help your re-enterancy problems ( and cut a
> swathe of code out of evolution ) that we can get into the platform in
> that timescale. My re-entrancy 'fix' is also also rather simple, so I'll
> explain it to you: [ thanks for provoking me into sharing this, since
> I'm supposed to write a formal proposal or somesuch and havn't got round
> to it ]:
> 
>       For each corba method we add an IDL [or other] annotation that
> describes the method behavior and (re-)ordering constraints. Thus:
> 
> +     oneway foo (in string baa) [ handle_at_idle, no_re_enter ];
> 
>       Or perhaps - for people who like blocking:
> 
> +     string getMyName () [ no_re_enter ]
> 
>       Thus people can invoke methods, no re-entrancy will occur on that
> method invoke, and we can queue methods execution until idle. It's
> really quite easy to do in the ORB - but needs some IDL extensions /
> poking. Possibly some evil #pragma or something. Then we are at least at
> the X level - where incoming events are processed in an idle loop, and
> outgoing events don't re-enter [ but of course can do if we think we can
> cope with writing some re-entrancy safe code ].
> 
>       How does that sound ?

Honestly - like a big hack.

But, given the nature of orbit, i dont see any other solution, since
nobody wants to use threads.




_______________________________________________
evolution-hackers maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers

Reply via email to