Re: Bonobo Unique Application

Hi Gustavo,

On Mon, 2003-04-14 at 11:27, Gustavo J. A. M. Carneiro wrote:
>   Well, if you need a GEP for every trivial API addition to a library,
> then that library will probably progress very slowly, IMHO.

	True; but I know some other people are interested in this - I do think
we ought at least to have some GEP; I'm happy to write it up quickly.

>   Michael, this message comes a bit late. :)

	Sorry; things here are pretty busy right now.

>   Two days ago I sent a new version of this patch.  You'll find out that
> I tried using the POAManager holding state to accomplish reentrancy
> protection.  What is the advantage of this ORBitThreadHint solution
> compared to the POAManager holding state?

	The problem is that we don't want the incoming call to be processed in
the server at an unpredictable point (eg. an outgoing random gconf
call); thus we have to process the call at idle. Poking at the POA will
only cause subsequent incoming requests to be processed at the tail-edge
of the guard - which is not so useful ;-)

> ORBitThreadHint, on the other hand, is not standard, looking
> at the prefix, and probably not documented.  I don't even know which
> header to start looking at..

	Yes; that is certainly true; we need to create a new POA with this hint
set on it, and use that for the specific interfaces we're interested in
at construction time.

>   On the other hand, I had to use ORBit2 private API to get the
> POAManager, anyway, so I'm not completely happy with either solution.

	The 'do it at idle' process I suggested will (should) work well, and
avoid all of the known re-enterancy problems; of course, it's possible
that it needs some ORB-level testing, but it's not such a conceptually
difficult piece of code to fix.

	So - ... sorry to have this pain; but Alex is right - we need to
process the incoming call at idle (since we want to reply). My feeling
is that we also want some way of available message discovery for
bindings / making this more pleasant.

	Thanks,

		Michael.

-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot