[omniORB] Win32 Question

[Steven W. Brenneis]

Chris Hafey wrote:
> 
> At 08:45 AM 6/4/99 -0400, Steven W. Brenneis wrote:
> >
> >You are initializing the ORB and BOA from the OnInitDialog member of
> >your dialog handler class.  This method is invoked from the Dialog's
> >message handler thread, not from the main thread of the program.  This
> >can be done but is generally problematic.
> 
> I don't believe this is true.  A standard MFC application consists of one
> thread that runs the MFC message loop and passes dialog messages out to its
> dialogs.  So the "Dialog message handler thread" is the same thing as the
> "main thread of the program".  Even if it was a separate thread, I can't
> think of any reason this is problematic.  Can you explain?
> 

I guess some clarification is necessary here.  Here is an excerpt from
the MFC threading guide:

MFC distinguishes two types of threads: user-interface threads and
worker threads. User-interface threads are commonly used to handle user
input and respond to events and messages generated by the user. Worker
threads are commonly used to complete tasks, such as recalculation, that
do not require user input. The Win32 API does not distinguish between
types of threads; it just needs to know the thread's starting address so
it can begin to execute the thread. MFC handles user-interface threads
specially by supplying a message pump for events in the user interface.
CWinApp is an example of a user-interface thread object, as it derives
from CWinThread and handles events and messages generated by the user.

I should have asked whether the dialog was directly or indirectly
created from WinMain or from another method.  The dialog's message pump
may be in the WinMain thread or it may not be.  The point here is that
MFC will restrict access to (some or all of?) the resources of a window
and its associated handler class based on the thread context that
created the window.  omniORB threads will not be in that context and I
have experienced a wide variety of assertion failures and exceptions
when attempting to use a window's resources and those of it's associated
class from a CORBA-invoked method.

> >Also, you have made a single, non-blocking call to the BOA's
> >impl_is_ready in the OnInitDialog member function.  This will provide a
> >single pass through the dispatcher if there is an RPC invocation
> >waiting.  In order to process further RPC's you will have to make other
> >non-blocking calls to impl_is_ready or you will have to have a single
> >blocking call somewhere.
> 
> This is not true.  impl_is_ready(0,true) creates a background thread to
> process incoming connections/requests.
> 
> Chris Hafey

I hear what you and Duncan are saying, but I have never been able to get
an omniORB/MFC application to exhibit this behavior successfully.  For
that reason, I have attempted to separate the omniORB and MFC
implementations as much as possible.  The only completely successful
solution has been to create a separate Win32 API (not MFC, see above)
thread in which the blocking version of impl_is_ready is called.  I have
also been able to produce results by placing repetetive calls to
impl_is_ready in the OnIdle member of a CWinThread derived class.
However, if the CORBA methods invoked are very time-consuming, the
message pump seems to get tired and lock up the application or window. 
All other attempts have produced results similar to what Ryan Tecco has
(I think) experienced.

Hope this helps.
Steve Brenneis