> 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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Magnus Hagander wrote:

>>(*) 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.
>
>
>
>


I assume that this will not break the use of pg_ctl to deliver
pseudo-signals. That would be a show-stopper.

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

""Magnus Hagander"" <mha@sollentuna.net> writes
>
> 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.
>

Yes, the shared memory segment size could be controlled by MaxBackends.

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

Yes, use mutex.

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

To simulate kill(0) we can test the process handle, just like we handle
waitpid().

I have simplified the code according to the discussion. Now there is no pipe
or signaling threads, process access shared memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two choices to fix it:

(1) Record Shared memory name (it is already there) and the offset of
signaling shared memory in postmaster.pid; So the pg_ctl program can access
the shared memory (since it has write down the signal number there) and
SetEvent target process;

(2) Postmaster will startup a thread monitoring messages, pg_ctl simulate
"kill" by sending postmaster a message <target_pid, signum>, then postmaster
will forward this "signum" to "target_pid";

What do you think?

Regards,
Qingqing