Claudio wrote:
> That's a neat idea, but just have to be very careful here. Currently,
the
> code does a ReadFile, queues the signal, and then a WriteFile. Calls
to
> raise and/or kill to a process with a blocking signal queuing, as
written,
> would fail, and take up to a second to do so.
That is quite correct. I think a more robust implementation would to
have the pipe server spawn a thread and then continue listening. This
thread is now free to hang out forever for the mask to allow signal
execution. Now the pipe server thread is totally asynchronous from the
main thread.
> Also, and more pertinently, you may want to block some signals, but
allow
> others through. Not sure how you imagine this would be handled, at
least
> with a single event object, although perhaps I've misunderstood your
> intent.
See code snippets below (not built for safety, but you get the idea).
HANDLE signal_handler_table[PG_SIGNAL_COUNT];
static void pg_queue_signal(int signum) {
if (signum > PG_SIGNAL_COUNT)
return;
if (NULL != signal_handler_table[signum])
{
WaitForSingleObjectEx(signal_handler_table[signum],
INFINITE, false);
}
QueueUserAPC(pg_signal_apc,pg_main_thread_handle,(ULONG_PTR)signum);
}
int sigblock(int mask) {
int prevmask;
prevmask = pg_signal_mask;
/* small loop compares masks runs over hadle table, creating
events and removing them as necessary. */
pg_signal_mask |= mask;
return prevmask;
}
Thus, each backend allocates a handle for each blocked signal *or* keeps
a handle table for all signals which could be blocked.
Merlin
