Re: libpq/async notifications

Hi

Is there a way to only check if there's any pending async notifications ?
I've found only PQnotifies(..) but it also removes the first notification from
the list.
A function for only checking this can be used in a gui app to setup async
notifications processing so it happens only after an app reaches it's main
loop (which is a good idea since it won't happen in the middle of another
app's handler function which happens to use pgsql database interface).
Currently I have to check for notifications with PQnotifies every time my app
returns to the main loop after using any of PGexec, etc, which is not very
efficient.

The check function is as simple as:

int PQhasNotifies(PGconn *conn)
{
if (!conn)
return NULL;

/* Parse any available data to see if we can extract NOTIFY messages*/
parseInput(conn);

return NULL != DLGetHead(conn->notifyList);
}

--
Best regards,
Igor Shevchenko

Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx> writes:
> Is there a way to only check if there's any pending async notifications ?
> I've found only PQnotifies(..) but it also removes the first notification from
> the list.
> A function for only checking this can be used in a gui app to setup async
> notifications processing so it happens only after an app reaches it's main
> loop (which is a good idea since it won't happen in the middle of another
> app's handler function which happens to use pgsql database interface).
> Currently I have to check for notifications with PQnotifies every time my app
> returns to the main loop after using any of PGexec, etc, which is not very
> efficient.

"Not very efficient"? This seems like a very weak argument. The actual
cost of running the function is no different from PQnotifies in the case
where no notify event is found; and in the case where one is found, it'd
be slower because you'd then have to call PQnotifies anyway to remove
the item from the list.

Yes, I know the function is only five lines, but there are also
documentation and other maintenance costs to consider anytime we add
something to libpq's API. I don't think you've made enough of a case
for it.

regards, tom lane

On Tuesday 14 October 2003 19:10, Tom Lane wrote:
> Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx> writes:
> > Is there a way to only check if there's any pending async notifications ?
> > I've found only PQnotifies(..) but it also removes the first notification
> > from the list.
> > A function for only checking this can be used in a gui app to setup async
> > notifications processing so it happens only after an app reaches it's
> > main loop (which is a good idea since it won't happen in the middle of
> > another app's handler function which happens to use pgsql database
> > interface). Currently I have to check for notifications with PQnotifies
> > every time my app returns to the main loop after using any of PGexec,
> > etc, which is not very efficient.
>
> "Not very efficient"? This seems like a very weak argument. The actual
> cost of running the function is no different from PQnotifies in the case
> where no notify event is found; and in the case where one is found, it'd
> be slower because you'd then have to call PQnotifies anyway to remove
> the item from the list.

The idea behind this checking function is to separate the *checking* if
there's any notifications and actually *processing* them. I want to check
right after any transaction or any PQ* function which calls PQconsumeInput
and process notifications only once, after my app had returned to it's main
loop (I'm talking about GUI apps here). In Qt, for example, this is done by
creating a new QEvent and dispatching it via QApplication::postEvent(...),
which is quite an overhead; with just PQnotifies I have to do this all the
time.

>
> Yes, I know the function is only five lines, but there are also
> documentation and other maintenance costs to consider anytime we add
> something to libpq's API. I don't think you've made enough of a case
> for it.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
Best regards,
Igor Shevchenko

Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx> writes:
> The idea behind this checking function is to separate the *checking* if
> there's any notifications and actually *processing* them. I want to check
> right after any transaction or any PQ* function which calls PQconsumeInput
> and process notifications only once, after my app had returned to it's main
> loop (I'm talking about GUI apps here). In Qt, for example, this is done by
> creating a new QEvent and dispatching it via QApplication::postEvent(...),
> which is quite an overhead; with just PQnotifies I have to do this all the
> time.

How so? Seems to me the check operation could read

notify = PQnotifies(...);
if (notify)
{
make QEvent, put notify pointer in it, dispatch
}

The event handler then fetches the notify pointer from the QEvent
(and eventually frees it).

regards, tom lane