Re: Event precedences

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Mon, 2 Nov 1998, Eskil Heyn Olsen wrote:

> Oy...
> 
> Another one, what if the queue contains at SetUserId to 42, and the pilot
> already has 76. Now when conduits are run, is the id 42 or 76 ? Should the
> id be set, and the conduits given the new, or use the old ?
> 
> eskil
> ---

My recommendation would be to process the immediate queue first.  Also, it
only makes sense to have an immediate queueing for the setuserid function
so the user id is always set first.  BTW, how did you decide to do the
first time setting of the userid since there is no way to tell which pilot
it is until after the user id is set?  Do you allow the app to chose a
device name?

Also, when configuring a new pilot on a system when the pilot is also used
with another system causes problems.  When adding the pilot the tool will
want to do the following.  Read the user id of the pilot and use it if it
isn't zero otherwise set the user id.  The problem here is that these
interactive requests must occur while the pilot is being synced, which
isn't a good thing.  We should have a call like,
set_user_id_if_not_zero(id).  The call returns the existing userid of the
pilot if not zero, or the set one if it is zero.  This avoids the
interactive problem.  The call should, of course, take a device name to
work with as well.

The other set_user_id call which just changes the userid for a given pilot
is simple, just queue it on that pilots immediate queue.  When the user id
is written to the pilot, the tool gets notified and can then update
gpilotd's configuration.  Though, this means we will need to have some
config file locking for these types of updates or a single CORBA server to
update gpilotd's config file.  I like option two.

Manish

Manish Vachharajani               Some Haiku: A crash reduces
<mvachhar@vger.rutgers.edu>                   your expensive computer
                                              to a simple stone - Unknown