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" <ch...@slort.org> To: "Tim Golden" <m...@timgolden.me.uk> Cc: "zz Python Win32 Newsgroup" <python-win32@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]m...@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@python.org http://mail.python.org/mailman/listinfo/python-win32 References 1. mailto:m...@timgolden.me.uk
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
