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

It shouldn't, but there is one concern: it has to be created in the
global namespace. On older windows there is no different, but on modern
windows with terminal services in it it does. It might require some
permissions hackings - I don't know what the default permissinos are on
these things. But I *think* it should work fine.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

""Magnus Hagander"" <mha@sollentuna.net> writes
> > I assume that this will not break the use of pg_ctl to
> > deliver pseudo-signals. That would be a show-stopper.
>
> It shouldn't, but there is one concern: it has to be created in the
> global namespace. On older windows there is no different, but on modern
> windows with terminal services in it it does. It might require some
> permissions hackings - I don't know what the default permissinos are on
> these things. But I *think* it should work fine.
>

Yes, the mutex/event stuff should be in the global namespace. What do you
mean the permission hacks?

Regards,
Qingqing