From: Igor Shevchenko <igor@carcass.ath.cx>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: libpq/async notifications
Date: Tue, 14 Oct 2003 19:46:07 +0300
Message-ID: <200310141946.07374.igor@carcass.ath.cx> (raw)
In-Reply-To: <9884.1066147821@sss.pgh.pa.us>
References: <200310111220.25923.igor@carcass.ath.cx>
<9884.1066147821@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: igor@carcass.ath.cx, tgl@sss.pgh.pa.us
Subject: Re: libpq/async notifications
In-Reply-To: <200310141946.07374.igor@carcass.ath.cx>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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