Re: ORBit server question

[Phil Dawes <philipd parallax co uk>]

Elliot Lee wrote:
> 
> On Wed, 2 Sep 1998, Michael Lausch wrote:
> 
> > I want to build a ORBit server which should support multiple clients
> > and multiple objects per client. Is this possible? From browsing the
> > example code on the redhat website
> > <http://www.gimp.org/~imain/ORBit-GTK/ORBit-GTK-1.html#ss1.5> it seems
> > that the only thing to do is to use the same server address in the
> > different clients.
> 
> yea duh
> 
> > Also is the ORBit server code thread safe? I'd like to make a MT server,
> > becuase some operations can last quite some time, so the other clients
> > will be not served during this time.
> 
> It is _supposed_ to be thread safe if you compile it with -D_REENTRANT in
> the CFLAGS, but I have not tested it, and I can think of a lot of places
> where it isn't thread-safe. Any help you can lend in this area would
> definitely be appreciated!
> 

I might be wrong here (haven't looked at the code for a couple of
weeks), but AFAIK ORBit uses a single-threaded reactive model to demux
its calls, so you won't have much luck with multiple threaded objects
out of one orb. 
You could try multiple threads with an orb in each thread, but I don't
much like your chances unless you don't mind changing a lot of code.

BTW If you do fancy implementing other threading models in ORBit, there
are a number of papers on the subject in Doug Schmits pages (once again)

Check out paper 2 on:
http://www.cs.wustl.edu/~schmidt/corba-research-performance.html

and it's worth reading about the following patterns: reactor,
acceptor/connector and active-object
http://www.cs.wustl.edu/~schmidt/patterns-ace.html


IMHO what ORBit really needs is a plug-in threading mechanism which
enables the model to be chosen at runtime according to the task the
server will perform. TAO uses the strategy and abstract-factory patterns
to achieve this flexibility.

A key issue is that the majority of gnome users will want to write
single-threaded reactive objects, since these are faster for low-latency
calls (which will compromise the majority of fine grained
component-based interactions). The designer of the MT mechanism in ORBit
must not force MT code into these servers (an area where OmniORB is
lacking AFAIK), and should try to keep locking overhead to a minimum
(factor it out with active-object and strategy) so as not to impede the
performance of these objects.

I do intend on working on making ORBit multithreaded, but first I want
to:
1) Get the C++ bindings into a workable state
2) Sort out support for shared memory objects (in-process collation)
3) Get the implementation repository up and running

so it'll probably be months off if you rely on me ;)


Cheers,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.