Re: Win32 signal code - first try

>> Here is a first sketch at Win32 signal handling. First a couple of
>> comments:
>
>Couple of quick questions/points regarding your implementation:
>
>1. Fully support your decision to use named pipes.
>
>2. __pg_signal_count is guarded by a CriticalSection. Are
>Interlocked{Exchange / Increment} still necessary?

If we only used it inside the CriticalSection, they would be
unnecessary. But we also check the variable outside the critical section
in the polling function.

>3. you are absolutely certain that
>__pg_poll_signals() +
>EnterCriticalSection +
>memset +
>if... +
>LeaveCriticalSection +
>if...
>
>is more efficient than a single call to WaitForSingleObjectEx() with 0
>timeout?
Almost :-) I remember doing some tests no this earlier, but I have no
numbers around.

>> * Does *not* use user APCs. Why? Well, we had to use
>polling. And with
>> user APCs we'd have to go into kernel mode (however briefly) on every
>> poll. I replaced that with a simple counter that is checked.
>Thast way
>> we don't slow down the main path of the program much.
>
>Have you have given up on using a kernel mode driver to throw a thread
>into alertable state?

I think we agreed that we'd go with the polling method if it worked well
enough, so we don't need a kernel driver. If that doesn't work out, the
kernel driver would be the fallback method.

From your other mail:
> Some crude tests show that my 1 GHz P3 can execute about 1.2 million
> calls to WaitForSingleObjectEx() in 1 second. However, this is about
> 3.5 times slower than a quick mock up of your polling function I put
> together. Either approach, though, is pretty darn quick :). Unlike
> SleepEx(), WFSO does not stall the thread.

Hmm. Depending on how often we need to poll (meaning how often we need
to deliver signals), perhaps we can go with the WFSOEx method anyway.
The code would be slightly easier:
I've attached a version that uses this one instead.

(You'd probably move the WaitFor()... call into the #define as well)

Looking at this code, I'm thinking we can probably do away with the
critical section alltogether. All that code now executes on the main
thread. Does this seem correct?

//Magnus