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

[Christopher Nilsson]

Hi all,

On 12 March 2010 02:31, Tim Golden <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20100312/67bb550c/attachment.html>