Some other thoughts:

1) I could just create a separate OS startup script that only runs
once on boot and always forcibly removes the PID file (or just runs
qp -d if stop_durus() removes the pidfile). Kind of kludgey but it is
an edge solution for an edge case.

2) Have is_durus_running() try to lock the database file and use it
like this:

site.stop_durus()
while site.is_durus_running():
   time.sleep(1)
site.start_durus()

3) Change the process name (i.e. mess with argv[0] using the
proctitle module or make a system call with ctypes) to something like
"durus@7000" so we can check by process name that it is running. I
kind of like this idea regardless because it's tricky identifying
which process is the durus server anyway without referring to its
pidfile. Lot's of portability issues with this one though.

I'm leaning towards 2. Or, if is_durus_running() doesn't get
modified, I could just sleep for say 3 seconds between the stop_durus
and start_durus calls to create a big enough window where the odds of
a race condition are essentially none. Still a little kludgey but
should be effective enough.

> I think there will always be the remote possibility of a race,
> even if we check that locks are available.    The critical thing
> is that only one writer wins the race.

True. However, it looks like start_durus doesn't retry if Durus can't
lock the database file; Durus just exits with a RuntimeError. Then
start_durus calls wait_for_server and after a timeout, exits the
parent process raising SystemExit. I suppose I could catch SystemExit
and assume what happened to the Durus process and try to start it
again....

Dave

------
David K. Hess
Verscend Technologies, Inc.
dhess@verscend.com
214-684-5448



On Mar 27, 2007, at 5:17 AM, David Binger wrote:

>
> On Mar 26, 2007, at 10:31 PM, David K. Hess wrote:
>
>> However, if durus *did* happen to be running, will I run into a
>> new race condition between the previous durus giving up the lock
>> on the database file before the new one tries to lock it?
>
> I think there will always be the remote possibility of a race,
> even if we check that locks are available.    The critical thing
> is that only one writer wins the race.
>
>> Pondering how to handle that makes me start to think that maybe
>> is_durus_running might be best off trying to get a lock on the
>> database file.
>
> I think that is interesting, but it just moves a potential
> race to a different place, since the lock must be released
> before the real durus server starts.
>
> We do have a similar is_web_running() function that does
> not have a lock to examine.
>
>
>
>
> _______________________________________________
> QP mailing list
> QP@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/qp