Re: [HACKERS] Proposal for async support in libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Proposal for async support in libpq
Date: 1998-04-19 23:57:45
Message-ID: 9169.893030265@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ocie(at)paracel(dot)com writes:
> When the Postgresql library installs its signal handler for SIGURG, it
> can find out if one was already in place. If so, it can check to see
> if the SIGURG is for that other handler and the postgres handler can
> call the other handler.

Cool ... but what makes you think that you get to go second? The app
could install or remove its SIGURG handler at any time.

Also, how would you tell whether the SIGURG was "for that other
handler"? As Bruce pointed out, the signal may be delivered before any
OOB data is actually available to be read; therefore there is no way for
the signal handler to be sure whether the SIGURG came off the postgres
socket or some other one.

Basically, the Unix interface to OOB data is too brain-damaged to
be useful with more than one source of OOB data :-(. We can usefully
use it in the backend, because we can just declare that that's all the
backend will ever use OOB input for. But I don't think we can make
the same choice for frontend applications.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message bdboy 1998-04-20 08:37:31 Help me please.
Previous Message Tom Lane 1998-04-19 23:49:57 Re: [HACKERS] Proposal for async support in libpq