[omniORB] Fwd: How to make an application which is both an omniorb client and TAO server

[renny.koshy at rubixinfotech.com]

Duncan:

We have had cases where we use third party libs which REQUIRE a *single* 
thread to access them.  Access from any thread other than the one that 
initialized the lib will cause the lib to go crazy (even when those 
accesses are sequential).... In those cases, we've had to use a 
"worker-thread" model to de-couple the ORB threads and mux them into the 
single main thread....

Having a reactor would eliminate the need for this kind of a work-around 
in those cases.

Regards

Renny Koshy





Duncan Grisby <duncan at grisby.org>
07/01/2004 02:47 PM

 
        To:     renny.koshy at rubixinfotech.com
        cc:     omniorb-list at omniorb-support.com
        Subject:        Re: [omniORB] Fwd: How to make an application which is both an omniorb 
client and TAO server


On Thursday 1 July, renny.koshy at rubixinfotech.com wrote:

> Having given my advice against TAO as a pure "ORB"...  It does have the 
> nice little concept of Reactors... which allows people to tie in other 
IO 
> handles into the ORB's "select" loop....
> 
> Would that be too much work to add reactors into omniORB in some 
> standardized fashion?  i.e. a class "omniReactor"

As I understand it, TAO's reactor model is there to enable
applications to hook into the select loop when the system is being
used single threaded. omniORB always uses threads, so I'm not sure
what the advantage of the application being able to share omniORB's
select would be.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040701/b80a17cc/attachment.htm