Re: Building gnome-pilot

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Thu, 17 Sep 1998, Eskil Heyn Olsen wrote:

> On Wed, 16 Sep 1998, Manish Vachharajani wrote:
> 
> > Where is MergeToRemote and MergeFromRemote supposed to be defined in the
> > memo conduit?  I haven't had a chance to look closely at this yet but I
> 
> I'm still not sure, but suspect that I forgot to commit a pilot-link with
> MergeFromRemote, but thats done now. Rebuild pilot-link, and they should
> be there.
> 
> > Also, Eskil, what are your plans for adding the CORBA support to gpilotd?
> > Should I try to add support for global gpilotd this weekend if I get a
> 
> I plan to try and implement request_file_install and request_restore. I am
> still pondering on whether to use threads or not (if there are too many
> shared queues, I won't, simply to keep the chance of errors down).

In local gpilotd there will be an immediate shared queue and a delayed
shared queue and that's it.  You just make sure when you fork, the child
only has one thread and we set up the signaling and we are fine.  We can
even omit fork and set up a separate thread to do syncing if we are going
to use threads.  This will actually make queue management easier.

I am worried about global gpilotd however.  First, we must fork so we can
setuid to the user for security and protect other queues from bad coding
like buffer overruns etc.  Second, with threads here, there will be a
queue for every user that has queued events.  This can be stored in a list
or hash table or something but there will be a lot of lists.  On the other
hand the locking code should be generic, and if done cleverly, can be
shared between global and local gpilotd.  The problem is that we want to
fork with global gpilotd and this means we still need queue management.

Threads do have the benefit of making queue management easier though.
Maybe we can set the uid of just one thread?  Does POSIX threads support
this?  If this is possible I wouldn't worry so much about memeory
integrity since we can fix coding bugs :).  Now the only other question
with threads is, what about portability?  How widespread is POSIX threads.
I will be happy if it works reasonably on the following OSes

Linux i386/Alpha/Sparc/Sparc64/PPC since these kernels are used on a large
number of machines that are still being manufactured and are fast enough
to run GNOME. Well not sparc, but they have a large installed base :). 
Maybe also MIPS, ARM, m68k, and the other arches.  I beleive that most of
the arches have POSIX threads

Solaris 2.5.1, 2.6, etc.  Forget SunOS, many people still use it but they
should have upgraded when Solaris 2.4 came out.  It was an ok release.  I
believe that 2.5.1 and 2.6 have good threads support.

FreeBSD, and NetBSD.  Don't know if they have POSIX threads.

IRIX, I hope they have working POSIX threads :)

HPUX, see IRIX

Digital UNIX, Hmm, do we care, they should run Linux :).  Seriously, I am
not sure if Digital UNIX has POSIX threads.
 
> I will probably make a library like the panel_applet lib, that
> encapsulates the corba calls. 

Yes this needs to be done and is independent of gpilotd

> Also I will try the method of creating .REQ files somewhere, that we
> discussed some time back, to ensure requests survice a gpilotd kill.

These should probably go in a hidden directory where user files are
spooled.  Did we ever finally decide on where spooled files go?  Why in
/var/spool/$USER and not in the users home dir?  I would prefer the users
home dir, but we had this discussion and I don't remember the outcome.

> Should I do it all down in drafts/idl, or a seperate branch, or just in
> the current source dir ?

If you can do it in one quick commit, meaning one or two days, do it in
the main branch.  If the work will span weeks, or take multiple commits
make a branch.  I will try to add global support for what we have now this
weekend to the main branch.  This is, of course, unless we decide to use
threads. If we use threads, then we should create a new branch and you and
I can both work on a threads version in that branch.  This way people will
still have a working gpilotd until the new stuff is done.  Then we can
just merge back to the main branch. 

> And I hope to look at it this weekend.

Ok.  Let me know about the threads decision ASAP.  I can't look into it
now since I am still trying to get everything with school set up.  First
year at grad school you know :).

Oh, also to answer one of your earlier questions Eskil, I will either be
grading papers or teaching a lab section for a Computing Structures
course.  Basically, a course on how to implement register transfers and
other basic CPU functions using finite state machines, etc.

> eskil
> ---

Manish Vachharajani
<mvachhar@vger.rutgers.edu>