Re: Preventing multiple startups of Gnus by the same user?

[Lloyd Zusman <ljz@asfast.com>]

Andrew J Cosgriff <ajc@bing.wattle.id.au> writes:

> Lloyd Zusman wrote :
> 
> > Suppose I have started up XEmacs as a certain user on my machine,
> > and this XEmacs process is running Gnus.  [ ... ]
> > [ ... ] What I'd like to do is for
> > this second Gnus to never start up because there's another one
> > running as the same user ID within a different process.
> > 
> > [ ... ]
> 
> Do you run gnuserv ?  Only one instance of gnuserv can run per user,
> so if you start it a second time in a second copy of emacs it'll die
> straight away - perhaps just before you try starting gnuserv in your
> .emacs you could run "gnuclient -eval '(gnus-alive-p)'" and see what
> it says - if there's already a copy of XEmacs running gnuserv that's
> running gnus, it'd work.

Thanks for this suggestion.  I do run gnuserv and hadn't thought of
this, and I was able to code up something that works pretty much
the way you suggest.

However, this approach has a race condition that I don't know how to
get rid of.  To explain the race condition, I first have to show you
my new Gnus startup code:

  (gnuserv-start)
  (sit-for 3)
  (cond
   ((eq (process-status gnuserv-process) 'run)
    (gnus))
   (t
    (message "user %s: another Gnus is running" (user-login-name))))

It turns out that `gnuserv-start' returns right away, before the
gnuserv executable itself can determine whether there's another
instance of itself running or not.  Right after `gnuserv-start'
returns, the status of that process is always "run".  Only after a
short while does the status change to "error" if there's another
gnuserv process.

I looked through the gnuserv.el elisp code and there doesn't seem to
be any way to avoid this race condition.  Even `gnuserv-init-hook'
doesn't help me, because it too is affected by the same race condition
(i.e., I'd have to wait a couple seconds inside of that routine also
in order to detect whether or not the gnuserv process failed).

I can live with this race condition, since the code I wrote works
and I can always increase the `sit-for' time.  But is there any
way to eliminate this race condition altogether? ... or maybe
yet another approach to accomplish what I want?


> [ ... ]
> 
> HTH.

Indeed is has helped, since as I mentioned, I can minimize the effects
of the race condition.  Thank you very much!

-- 
 Lloyd Zusman
 ljz@asfast.com