Re: [HACKERS] Anyone working on asynchronous NOTIFY reception? - Mailing list pgsql-hackers

>
> Mattias Kregert <matti@algonet.se> writes:
> > Async communication between backend and frontend would be really nice.
> > I use Tcl a lot and I really miss this. It would be wonderful to have
> > libpgtcl do callbacks, so that info on-screen could be automagically
> > updated whenever something changes.
>
> Yes, if anything were to be done along this line it'd also make sense
> to revise libpgtcl.  I think it ought to work more like this:
>   (a) the idle loop is invoked while waiting for a query response
>       (so that a pg_exec statement behaves sort of like "tkwait");
>   (b) a "listen" command is sent via a new pg_listen statement that
>       specifies a callback command string.  Subsequent notify responses
>       can occur whenever a callback is possible.
> I suppose (a) had better be an option to pg_exec statements so that
> we don't break existing Tcl code...
>
>             regards, tom lane

There is already some support for async notify in libpgtcl, it was and old
patch of mine. It does exactly what you are thinking of, except for the
idle loop stuff. You can setup callbacks for specific relations and then
periodically issue a command which checks for pending notifications and does
the callbacks if any is found. Note also that you can listen on any name,
not just for existing relations.

I have a Tcl/Tk application (used concurrently by more than 30 users)
which uses heavily async notifications to notify clients when some events
occur. It uses a timer inside the application which polls the server every
n seconds (actually 1 second) for pending notifies.
It works well but it is a really big bottleneck for the application and I
had to spend a lot of time to debug and patch the code in async.c.
It seems that nobody beside me has ever used this feature because I didn't
see any bug report on the mailing lists (and there were many).

The biggest problem is that if you have many clients listening on the same
thing they are signaled at the same time and all of them try to access the
pg_listener table for write. The result is that you have a lot of waits on
the table and sometimes also deadlocks if you don't do things carefully.

From the Tcl side, a better solution would be to define a tcl event handler,
like the standard Tcl filehandler, which would be invoked automatically by
the Tk event loop or by tkwait if using pure Tcl.

I have also some new patches which try to reduce the notify overhead by
avoiding unnecessary unlocks of the table. If you are interested I can
post them.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto                e-mail:  dz@cs.unitn.it            |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+