[omniORB] Win32 Question

[Steven W. Brenneis]

ryan.tecco wrote:
> 
> All right, here is a little snip of what I am doing. It is basically based
> on the eg2_xxxx samples.
> 
> class MyObject : public virtual _sk_MY
> {
> public:
>         MyObject();
>         virtual ~MyObject();
>         virtual char* request();
> };
> 
> BOOL CMyDlg::OnInitDialog()
> {
>  ...
>  int argc = 0;
>  CORBA::ORB_ptr orb = CORBA::ORB_init(argc, NULL, "omniORB2");
>  CORBA::BOA_ptr boa = orb->BOA_init(argc, NULL, "omniORB2_BOA");
>  my_impl = new MyObject;
>  my_impl->_obj_is_ready(boa);
>  MY_var objRef = my_impl->_this();
>  CORBA::String_var temp = orb->object_to_string(objRef);
>  std::ofstream outFile("iiop.txt", ios::out);
>  outFile << (char *)temp;
>  outFile.close();
>  boa->impl_is_ready(0, 1);
>  ...
> }
> 
> void CVoiceRecDlg::OnCancel()
> {
>         delete my_impl;
>         CDialog::OnCancel();
> }
> --------------
> ryan.tecco
> 734.647.8057
> microcosm/CAVE programmer
> the university of michigan
> "when all the pettiness is gone,
> what do we really have?"
> 
> On Thu, 3 Jun 1999, Bruce Visscher wrote:
> 
> > Ryan,
> >
> > If I had to make a WAG, it would be that you failed to duplicate an object
> > somewhere in the server.  If you could post a small example with
> > implementation that exhibits the problem then maybe someone could help.
> >
> > Bruce
> >
> > "ryan.tecco" wrote:
> >
> > > I am running WinNT 4.0 SP3 and MSVC++ 6.0. I am writing an MFC
> > > application. One of the objects within the main dialog is a object that
> > > inherits from the CORBA skeleton. My client is able to connect fine, run a
> > > remote method fine, but right after it runs it once, the server throws a
> > > variety of debug assertions located in "object.cc" and some other files. I
> > > switched to the run-time libraries, but then I got a more serious error.
> > > It just looks to me like I am not initializing or doing something properly
> > > (being new to CORBA and all ;) Please let me know any suggestions if this
> > > sounds at all familiar.
> > >
> > > rt
> > >
> > > --------------
> > > ryan.tecco
> > > 734.647.8057
> > > microcosm/CAVE programmer
> > > the university of michigan
> > > "when all the pettiness is gone,
> > > what do we really have?"
> >
> >

Ryan,

>From what you have included, it is difficult to tell where the server is
going astray, but there are a few general items with regard to omniORB
on Win32 that need to be addressed in what you are doing.

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.  It is usually better to
initialize the ORB and BOA directly in WinMain or from the MFC provided
member of the application class, OnInitInstance.  Threads created from
and by omniORB are independent worker threads and function as most of us
would expect.  MFC threads, however, have a number of restrictions that
cause problems when they interact with *normal* threads.  The ORB and
BOA are singletons so they are available application-wide from wherever
they are initialized.  You can get your needed reference to the BOA as
follows:

	my_impl->_obj_is_ready(CORBA::BOA::getBOA());

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.  Using the blocking call in an MFC application
will require a separate thread since blocked MFC threads are generally a
no-no.  You can put non-blocking calls to impl_is_ready in your
application's OnIdle message handler, but you will have to be careful
that none of your RPC's attempt to access the resources of other Windows
in the application.  MFC will not allow this.  You will also have to
make sure that none of your RPC's are starving the main window's message
queue handler for time or your application will lock up.

Hope this helps.

Steve Brenneis