| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx> | 
| Cc: | pgsql-interfaces(at)postgresql(dot)org | 
| Subject: | Re: libpq/async notifications | 
| Date: | 2003-10-14 17:18:29 | 
| Message-ID: | 10861.1066151909@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-interfaces | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brett Maton | 2003-10-15 08:22:17 | Intercept database Connection request | 
| Previous Message | Igor Shevchenko | 2003-10-14 16:46:07 | Re: libpq/async notifications |