Re: ORBit thread safe ? was Re: gpilotd & corba

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Sat, 19 Sep 1998, Eskil Heyn Olsen wrote:

> On Thu, 17 Sep 1998, Manish Vachharajani wrote:
> 
> > > that so bad as opposed to the risk of threadrelated errors/load of
> > > continously spawning threads ? 
> > Well is ORBit threads safe?
> 
> Dunno, Mike, could you ask Elliot ? Anyways, I plan to let orb methods run
> in one thread alone, and the other threads won't do any orb stuff. Thus
> from ORBit's point of view, it'll look like it is a single process.
> 
> > > notify system), that perhaps should be threaded, or the calls should be
> > > declared as oneway (maybe the best approach).
> > Probably have the calls be one way.
> 
> Cast in stone then.
> 
> > What about the portability aspect?  The locks should be generic.  Also
> 
> Either we could "pthreads is POSIX, support or die" and use pthread_mutex*
> calls for locks, or we could make a more or less redundant wrapper layer
> on top on pthreads.
> 
> Or a less redundant layer, that eg. had calls like g_list_lock(GList*),
> g_list_try_lock(GList*) and g_list_unlock(GList*), which uses a ghashtable
> for matching pthreads mutexes with glists (and other g_things). 

This seems like a good idea.  I think that datasets in glib should let us
do this easily, but i am not sure.
 
> Perhaps there already is such a set of methods ? If not, it might be
> generic enough for other uses.

I am not sure how useful the locks would be though, in glib.

> > what about switching uids on threads.  We MUST have this for security in
> 
> But no can do. uids are still on process level.

Ok, in that case we will have to fork and have some type of communication
between the parent and the child, such as a pipe so that the child can
signal the parent as to which queued elements it processes.  Remeber, we
need to know exactly which queued elements, because a sync could be
cancelled.

Hmm, which reminds me, if a sync is cancelled should the unprocessesd
requests be purged or kept for the next sync?  I vote for keeping them
around and having a pilot manager program, perhaps executable from the
capplet, to look at and manage the request queue, sort of like the windows
print manager.

> (btw, having been bartending 10 hours last night, I think I safely can say
> I won't be touching much corba stuff this weekend).

> eskil

:).  Well at least you had fun.  I have been trying to read through 8
chapters in a book on switching theory since the professor is going to
assume that we know that material.  I know the material but have never had
a formal course so I need to catch up.  Ugh.  I will devote whatever time
I can to coding though :).

Manish Vachharajani
<mvachhar@vger.rutgers.edu>