Single threading and CORBA_Object return types

[Bill Haneman <bill haneman sun com>]

Hi:

I am trying to understand some behavior I am seeing and would like
confirmation that it is a consequence of ORBit's single threading, and
solicit suggestions for dealing with it.

I am obtaining an instance of a registry object from OAF, and then
need to query it (in a client).  It appears to me that if the client
calls any functions that return CORBA_Object references, the return is
accomplished via a push-IIOP stream from the server to the caller.

This works fine if I make one such call; and I get the reply without
entering the corba event loop (which I do via bonobo_main()).  However
if I make two such calls in my client without entering bonobo_main the
second call blocks in 

__select()
__DTOR_END__ ()
giop_main_next_message_2 (blocking=1, ...)
giop_recv_reply_buffer_use_multiple_2 (..., block_for_reply=1)
giop_recv_buffer_use_2 (..., block_for_reply=1)
<my client-side CORBA call is here in the stack>

Is this a single-threading issue, as I expect?  If so, what is the
recommended workaround so that my client can programmatically query
the service?  The problem only arises with calls that return
CORBA_Object derivatives, not calls that return simple data types.

Believe me, I have been wading through gdb for awhile, my client-side
call is not calling back into the requestor.  The block seems to occur
when the service tries to return the CORBA_Object to the caller, but
only the second time.

Puzzled,

Bill

-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland