Re: Multi-threaded

[Toralf Lund <toralf lund pgs com>]

Frank.Rehberger wrote:
> Duncan Grisby wrote:
>   
> > On Wed, 2010-06-02 at 14:21 -0400, Brent Baccala wrote:
> >   
> >     
> > > On Wed, 2 Jun 2010, Toralf Lund wrote:
> > >
> > >     
> > >       
> > > > First question: Is this list actually alive???
> > > >       
> > > >         
> > > Yes, barely.  I'm a late comer, but it looks to me like the free
> > > software community experimented with CORBA for a few years and then
> > > (for some good reasons) largely abandoned it in favor of other
> > > approaches.
> > >     
> > >       
> > I don't think that's quite the case. It is true that the people who
> > originally built ORBit experimented with CORBA then abandoned it in
> > favour of other things, but other free CORBA implementations like
> > omniORB (which I maintain) and TAO are still in wide and active use.
> >   
> >     
> I can confirm that omniORB, TAO (and JacORB) are the best ORBs
> available. And widely used. Still, CORBA has a number of features not
> available for SOAP, JSON or other application layer protocols.
>
> The pure C-ORBs such as eORB and ORBit2 are facing a second spring in
> the context of embedded systems currently.
>
>
> Toralf,
>
> the memory management of ORBit2 objects can be a bit tricky. If a large
> memory footprint is no problem, using TAO might avoid some headaches and
> speed up development.
>   
I think I've got the memory handling right by now. And probably 
everything else that needs to be done for the current requirements of 
the main software. The problem is that if those requirements change in a 
non-trivial manner, updating the CORBA code is very hard due to the 
nearly complete lack of documentation for (anything but the very simple 
features of) ORBit2.

The multi-threaded thing is a project on the side, by the way - I'm just 
trying to replicate the interface normally provided by our supplier, 
purely for debugging purposes.
> AFAICS, if you would adapt TAO ORB to integrate into glib::main_loop,
> TAO might be the better choice. The C++ language binding of CORBA is
> much easier to use. All you have got to do is to write an ACE::Reactor,
> similar to the one available for Qt:
>
> https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/ace/QtReactor/
>   
I only had a brief look, but it may seem like this "polls" the CORBA 
status via a timer, and forwards any events found to the Qt main loop 
via a custom pipe. I don't think this is full integration at the level 
ORBit2 offers, as this (again, as I understand it without checking 
source code too closely) hooks the actual communication socket used for 
CORBA data into the main loop. Which just feels nicer, although it may 
not make that much difference at the practical level ;-/

- Toralf



This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.