> Currently PG win32 port mainly does the following to simulate signals:
>
> (*) the process who kill the signal:
> - put the signal in a named pipe, then it is done;
>
> (*) the process who should receive the signal:
> - a non-stop thread "pg_signal_thread" will read the signal
> from the pipe, and start another thread
> "pg_signal_dispatch_thread", which puts the signal in a local
> memory variable "pg_signal_queue" and
> SetEvent(local_memory_event_variable);
> - the main thread of this process could be awakened by the
> event from waiting status(like semop()) or
> CHECK_FOR_INTERRUPTS() actively;
>
>
> Could we simplify this process like this:
>
> (*) the process who kill the signal:
> - put the signal in a *shared memory variable
> pg_signal_queue* and
> SetEvent(*shared_memory_event_variable*), then it is done;
>
> (*) the process who should receive the signal:
> - the main thread of this process could be awakened by the
> event from waiting status(like semop()) or
> CHECK_FOR_INTERRUPTS() actively; -- there is no other threads
> of this process;
>
> Any show-stop reasons of not doing this?
Yeah, that should work. With one shared memory segment and one event for
each process, of course. The event can be the same one as is used now,
only it has to be named so it can be accessed externally.
It would do away with the thread, certainly. But it's not quite as
simple as you outline above - you'll need to replace the critical
section locking (easy, lightweight) with a mutex or something like that
(more complex, more heavy weight). But probably named pipes is more
heavy, yes.
You'll also need some way of delivering the feedback, I think - kill(0)
is supposed to tell you if there is a live process in th eother end, so
you can't just throw the signal out and hope for the best.
I think the named pipe parts of things is a leftover from back when we
were using APCs to interrupt the main thread - which required a separate
thread. But since we can't do that, this sounds like a reasonable
simplification.
//Magnus
