Re: [HACKERS] Proposal for async support in libpq
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Proposal for async support in libpq |
Дата | |
Msg-id | 9169.893030265@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal for async support in libpq (ocie@paracel.com) |
Список | pgsql-hackers |
ocie@paracel.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
В списке pgsql-hackers по дате отправления: