>>Maybe. I'm not quite convinced of that yet - we can SleepEx with
>>a very small timeout, no? There must be a few critical places the
>>call could be made, which would in effect just delay delivery of
>>the signal for a very short time to some convenient sequence point.
>
>FWIW that method gets my vote - calling SleepEx(0) in some critical
>places; I believe that will yield the CPU but not wait any time (so if
>nothing else wants the CPU and there aren't any procedures that need
>calling then it amounts to a no-op).
Correct, SleepEx(0) with nothing to do will only incur the cost of a
switch to kernel mode and back. If other threads are runnable at the
same priority level, they will get scheduled, but no actual sleeping is
done.
I agree that that one is probably the best one, if it can be done at a
limited number of places. If we need to put hundreds of SleepEx()es int
ehre, that's just too much. I was under the impression that this was the
case, but perhaps we just need to research that line a bit more.
I guess you'd also have to modify the lock manager in some way to make
it enter alertable state when waiting for a lock from a different
process, but that sholdn't be too hard. Haven't looked at all on that
code.
//Magnus