Re: Win32 signal code - first try

Magnus Hagander wrote:
> >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.

That makes sense.

> 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?

Yep, now everything becomes very lightweight implementation-wise.
Virtually all the code runs in the main thread.

One quick point:
WaitForMultipleObjectsEx(0,NULL,FALSE,0,TRUE); fails. Just as
WaitForSingleObjects(0, 0, TRUE) also fails.

It is not clear from the documentation if this sets the thread to
altertable, and I don't know if this is predictable behavior. My
timings were based on WFSOEx with a dummy event.

Also, all signals will be run FIFO. Is this acceptable? (maybe a unix
expert could chime in here).

Merlin

Merlin Moncure wrote:

>
>Also, all signals will be run FIFO. Is this acceptable? (maybe a unix
>expert could chime in here).
>
>
>

Stevens' APUE (if you do any Unix programming and you don't have this
book, run don't walk and get it ;-) ) says: "POSIX.1 does not specify
the order in which signals are delivered to a process. The Rationale for
POSIX.1 does suggest, however, that signals related to the current state
of the process, such as SIGSEGV, be delivered before other signals."

AFAIK we are not using any of the signals he is referring to in the
second sentence, so FIFO should be fine.

cheers

andrew