Re: ORBit 0.5.17 CORBA_ORB_perform_work implementation

[Matt Doar <matt trpz com>]

Funny, I've been on both sides of this. Five years helping develop and
integrate a dozen different ORBs for Vitria, I wanted all applications
which used our ORBs to call run() and let our loop control things. 

Now I am integrating ORBs into existing single-threaded applications, I
just want to periodically check for CORBA work and do it. This means I
want to set timeouts to be long enough for me to do my other work, and I
want to be able to choose a maximum time or maximum number of requests
to be processed during the CORBA call.

One solution I have seen implemented is to provide the threading model
for the user, complete with locks to access the CORBA side of things.

~Matt
mdoar@pobox.com

On Tue, 2002-09-10 at 10:09, Michael Meeks wrote:
> 
> On Tue, 2002-09-10 at 15:15, dahaverk@rockwellcollins.com wrote:
> > It may be a synonym...   But books on CORBA show the "perform_work" as an
> > exposed to the user function to use.
> 
> 	Sure - but it's broken by design IMHO.
> 
> >  e.g. from "Pure CORBA" By Fintan Bolton...
> 
> 	With all due respect Fintan Bolton seems to have no idea:
> 
> >  // C++ style example...
> > 
> >     keep_running = TRUE;
> >     while( keep_running) {
> > 
> >             if (orb->work_pending() ) { orb->perform_work() ; }
> >             process_user_gui_input();
> >  }
> 
> 	So; there are 2 choices here - either:
> 
> 	a) process_user_gui_input blocks, in which case we have 
> 	   an efficient idle state, but no incoming CORBA calls can
> 	   be processed until a GUI operation occurs
> 
> or
> 
> 	b) process_user_gui_input doesn't block - at which point the
> 	   application belts around these 2 graunched main-loops, 
> 	   slogging it's guts out and burning out your CPU / battery 
> 	   etc. [ which means a lot to me with a laptop ].
> 
> 	:-)
> 
> 		Michael.
> 
> -- 
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot