Re: re-enterancy ...
- From: Alex Hornby <alex anvil com>
- To: Michael Meeks <michael ximian com>
- Cc: Mark McLoughlin <mark mcloughlin sun com>,orbit <orbit-list gnome org>
- Subject: Re: re-enterancy ...
- Date: 13 May 2003 15:57:31 +0100
Hi Michael,
Working with C++ ORBS the rule tends to be that if you make a remote
call then it can be reentrant.
The only reason people put up with it is that the alternative is to have
your process not respond to incoming calls when making an outgoing call
- not good in a server.
The solution tends to be lots of locks - which means lots of dead locks
until you get them right. I'm not sure there is a middle ground.
Alex.
On Tue, 2003-05-13 at 15:40, Michael Meeks wrote:
> Hi Mark,
>
> I remember you having very fixed views on adding re-enterancy guards to
> client code; as in "Don't add a non-standard method" - and yet; having
> poked at the spec there seems no standard way to do this.
>
> I was hoping that the CORBA_Object_set_policy_overrides thing would
> work - but that's going to suck for concurrent users of the same object
> handle (a common scenario with async / threaded invocations).
>
> So - I'm back to:
>
> ORBit_small_push/pop_renterancy_guard (ORBitSmallGuard *);
>
> of some sort; with per cnx/impl/etc. settings.
>
> To re-cap this is the _client side_ phenomenon of uncontrolled
> re-enterancy we're trying to stop.
>
> Thanks,
>
> Michael.
>
> --
> mmeeks@gnu.org <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> orbit-list mailing list
> orbit-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/orbit-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]