Обсуждение: notify with payload (pgkill, notify)

Поиск
Список
Период
Сортировка

notify with payload (pgkill, notify)

От
James Mansion
Дата:
Is the intent to replace most uses of (pg)kill with a general
purpose messaging system between the processes, or
(just) to address notify per se?

(Presumably with 'fire-and-forget' and also rpc
semantics?  And pub-sub? And some sort of
write to an fd protected by an atomic flag to
elide multiple writes when the process hasn't woken
and acknowledged the ATTN yet?)

If pgkill is not used for signalling, could this reduce the reliance on 
signals
(except for trying to kill off processes) to the point
where ot becomes much less scary to link to libraries
that use signals themselves and/or threaded runtimes?


Re: notify with payload (pgkill, notify)

От
Andrew Dunstan
Дата:

James Mansion wrote:
> Is the intent to replace most uses of (pg)kill with a general
> purpose messaging system between the processes, or
> (just) to address notify per se?
>
> (Presumably with 'fire-and-forget' and also rpc
> semantics?  And pub-sub? And some sort of
> write to an fd protected by an atomic flag to
> elide multiple writes when the process hasn't woken
> and acknowledged the ATTN yet?)
>
> If pgkill is not used for signalling, could this reduce the reliance 
> on signals
> (except for trying to kill off processes) to the point
> where ot becomes much less scary to link to libraries
> that use signals themselves and/or threaded runtimes?



My intention is to revamp the listen/notify system, pure and simple.

If you have an alternative suggestion them you need to make it now.

We are not intending to use FDs for message passing. They will be stored 
in shared memory. See previous discussions for details:


http://groups.google.com/group/pgsql.hackers/browse_frm/thread/e63a5ac43e2508ce/e0892fb3316cc327?hl=en&lnk=gst&q=notify+payload#e0892fb3316cc327

http://groups.google.com/group/pgsql.hackers/browse_frm/thread/6a59675a3e11bedc/87e0ce6dd6cce6a6?hl=en&lnk=gst&q=notification+payload#87e0ce6dd6cce6a6


cheers

andrew



Re: notify with payload (pgkill, notify)

От
James Mansion
Дата:
Andrew Dunstan wrote:
> If you have an alternative suggestion them you need to make it now.
>
well, I'm not sure about the non-collapsing business but no matter.
> We are not intending to use FDs for message passing. They will be 
> stored in shared memory. See previous discussions for details:
>
I'm more interested in replacing the pgkill wakeup mechanism with 
something that is less sucky on Win32.
If you just want to send a wakeup then making a pipe RPC is crazy since 
it introduces a lot of scheduling.
A unix domain datagram socket to which processes can send one byte is 
enough to toggle the readability
if the socket without doing much transfer, and using an atomic flag in 
shm means that subsequent
wakeups can be elided until the process acknowledges the signal, which 
it should do before scanning the
shm queue.

I don't see any reason to pass the data through the kernel if you have 
the shm handling routines,
particularly if you have ones that handle spilling.

If you're happy with using signals on UNIX (and Tom suggested that 
SIGUSR usage and signal handling
might be one of the concerns about allowing threaded addins) then at 
least on Win32 it should be worth
adding a variant of kill which has a void return and does not try to 
return information about the validity
of the target process id.

Personally I try to avoid signals and would prefer an fd level-based 
signal.  But YMMV.

I was just wondering if what you're doing could be generalised as a 
'post to backend' system that can be
used for other duties in future, so you'd need a message type and 
payload blob rather than assuming
that the type is 'notify' and the payload is the payload length.

If you had a pgsql extension that was 'wait for notificiation' or 'wait 
for row in message table' then
the wakeup could essentially be directed at code in the target backend, 
rather than using it as a conduit to
target code in the client.

James