pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedlibpq/async notifications
4+ messages / 2 participants
[nested] [flat]
* libpq/async notifications
@ 2003-10-11 09:20 Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 16:10 ` Re: libpq/async notifications Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Igor Shevchenko @ 2003-10-11 09:20 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq/async notifications
2003-10-11 09:20 libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
@ 2003-10-14 16:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-10-14 16:46 ` Re: libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2003-10-14 16:10 UTC (permalink / raw)
To: Igor Shevchenko <igor@carcass.ath.cx>; +Cc: pgsql-interfaces
Igor Shevchenko <igor@carcass.ath.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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq/async notifications
2003-10-11 09:20 libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 16:10 ` Re: libpq/async notifications Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-10-14 16:46 ` Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 17:18 ` Re: libpq/async notifications Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Igor Shevchenko @ 2003-10-14 16:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces
On Tuesday 14 October 2003 19:10, Tom Lane wrote:
> Igor Shevchenko <igor@carcass.ath.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@postgresql.org
--
Best regards,
Igor Shevchenko
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq/async notifications
2003-10-11 09:20 libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 16:10 ` Re: libpq/async notifications Tom Lane <tgl@sss.pgh.pa.us>
2003-10-14 16:46 ` Re: libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
@ 2003-10-14 17:18 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 2003-10-14 17:18 UTC (permalink / raw)
To: Igor Shevchenko <igor@carcass.ath.cx>; +Cc: pgsql-interfaces
Igor Shevchenko <igor@carcass.ath.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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2003-10-14 17:18 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-10-11 09:20 libpq/async notifications Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 16:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-10-14 16:46 ` Igor Shevchenko <igor@carcass.ath.cx>
2003-10-14 17:18 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox