[python-win32] Technique to limit number of instances of our application under Terminal Server

python at bdurham.com python at bdurham.com
Fri Mar 12 15:33:51 CET 2010


Hi Christopher,

Thanks for your thoughts. I'm going to go back and re-test the
semaphor strategy using Tim's sample code.

My situation is very unusual in that the apps being run are often
buggy because they are early releases of software being tested by
a small team of testers. Our test team seems to test on a random
schedule (of course they would argue otherwise!) which means
there are spikes in demand on our server. The code I'm trying to
write doesn't need to be perfect - it just needs to be good
enough to protect us from ourselves :)

On the other hand, you might be suprised how many times our apps
get abnormally terminated so we do need a fairly accurate way to
track running instances or the entire process is not worth
pursuing.

Regards,
Malcolm


----- Original message -----
From: "Christopher Nilsson" <chris at slort.org>
To: "Tim Golden" <mail at timgolden.me.uk>
Cc: "zz Python Win32 Newsgroup" <python-win32 at python.org>
Date: Fri, 12 Mar 2010 12:38:29 +1100
Subject: Re: [python-win32] Technique to limit number of
instances of our application under Terminal Server
Hi all,
On 12 March 2010 02:31, Tim Golden <[1]mail at timgolden.me.uk>
wrote:

  The advantage of mutex's over semaphores would be that
  applications that
  terminate abnormally would have their mutex released, while
  applications
  using semaphors that terminated abnormally would leave their
  semaphore
  with an incorrect count?

  See above; I don't this mutexes and semaphores differ in this
  respect.

Actually, if you take the example of someone calling
TerminateProcess() against the process (or some other equally
fatal do-not-pass-the-finally-block abnormal exits), they will be
different.
In this case, a mutex will be unlocked, and another process'
waiting thread will get a WAIT_ABANDONED wake up.
For semaphores, the handles will be mopped up, but the available
count on that semaphore will not be incremented.  So if you've
got lots of other processes coming and being killed in this way,
you can easily run out of slots, even though there is only one
handle open on the thing.
It's a pity, since the semaphore way of doing this is much
cleaner and faster than the "bunch of mutexes" method.
If you've got some other way to guarantee that you'll see such
processes vanish (eg. grab a SYNCHRONIZE handle on it via
OpenProcess() -- these will get signalled when the process dies
normally or abnormally), then it's still workable, since you can
then call ReleaseSemaphore() yourself -- without having to wait
for the original holder to do it.  But now you've got two
problems (limit instances *and* notice when they die). :)
Or, maybe it's an acceptable risk.  How badly do you want to
fight TerminateProcess / death by Task Manager anyway?  And you
could argue that other kinds of abnormal explosions are bugs that
need fixing.  My vote would definitely be for the semaphore
method.
Cheers,
Chris.
_______________________________________________
python-win32 mailing list
python-win32 at python.org
http://mail.python.org/mailman/listinfo/python-win32

References

1. mailto:mail at timgolden.me.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20100312/8e92f356/attachment.html>


More information about the python-win32 mailing list