Horton

Thread

  1. Re: [HACKERS] Proposal for async support in libpq

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-04-19T18:02:33Z

    Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> I don't see any real need to issue outgoing notifications as OOB data.

> Well, if you are trying to prevent from sending queries through libpq to
> see if you have any notifications, how will you get notification without
> an OOB-generated signal?  The notification would have to come through a
> packet from the backend, and I thought you didn't want to have to deal
> with that?

No, I have no problem with getting a regular packet from the backend
when the notify condition occurs.  What I don't like is creating excess
network traffic above and beyond the notification packet --- especially
not having to "poll" continuously to see whether the condition has
occurred.  But using select() to wait for something to happen does not
induce network traffic.

The only advantage of sending outgoing notifications as OOB is the fact
that a SIGURG signal gets delivered to the recipient, which could be
used to trigger abandonment of some current operation.  But I have a
hard time perceiving where a client would want that, as opposed to
detecting the notify after it completes whatever it's currently doing.

Sending cancellation requests inbound to the server is exactly what OOB
is for, because there you must interrupt current processing to get the
desired result.  Outbound notify signals are a different thing IMHO.
An SQL NOTIFY is typically going to trigger new processing in the
client, not cancel an operation in progress.

There are positive reasons *not* to force applications to handle
notifies as OOB data, primarily having to do with portability and risk
of breaking things.  For example, consider a frontend app that already
deals with OOB/SIGURG on a different input channel.  If libpq takes over
SIGURG signal handling, we break the app.  If not, we probably still
break the app, because its signal handling logic is likely expecting
SIGURG only from the other channel.

In short, inbound OOB to the server is OK because we have control of
everything that will be affected.  Outbound OOB is not OK because
we don't.

> One issue raised
> by Stevens' "Unix Network Programming"(p. 333) is that the OOB
> signal(SIGURG) can arrive before the data is ready to be read.

Right.  One advantage of using OOB only for cancel is that the SIGURG
signal itself is the interesting event; you don't really *need* to get
the OOB data to know what to do.  You can read and discard the OOB data
at any convenient point, perhaps just before trying to read normal data
from the client channel.

			regards, tom lane

  2. Re: [HACKERS] Proposal for async support in libpq

    ocie@paracel.com — 1998-04-19T22:07:20Z

    Tom Lane wrote:
> 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> I don't see any real need to issue outgoing notifications as OOB data.
> 
> > Well, if you are trying to prevent from sending queries through libpq to
> > see if you have any notifications, how will you get notification without
> > an OOB-generated signal?  The notification would have to come through a
> > packet from the backend, and I thought you didn't want to have to deal
> > with that?
> 
> No, I have no problem with getting a regular packet from the backend
> when the notify condition occurs.  What I don't like is creating excess
> network traffic above and beyond the notification packet --- especially
> not having to "poll" continuously to see whether the condition has
> occurred.  But using select() to wait for something to happen does not
> induce network traffic.
> 
> The only advantage of sending outgoing notifications as OOB is the fact
> that a SIGURG signal gets delivered to the recipient, which could be
> used to trigger abandonment of some current operation.  But I have a
> hard time perceiving where a client would want that, as opposed to
> detecting the notify after it completes whatever it's currently doing.
> 
> Sending cancellation requests inbound to the server is exactly what OOB
> is for, because there you must interrupt current processing to get the
> desired result.  Outbound notify signals are a different thing IMHO.
> An SQL NOTIFY is typically going to trigger new processing in the
> client, not cancel an operation in progress.
> 
> There are positive reasons *not* to force applications to handle
> notifies as OOB data, primarily having to do with portability and risk
> of breaking things.  For example, consider a frontend app that already
> deals with OOB/SIGURG on a different input channel.  If libpq takes over

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.

Ocie

  3. Re: [HACKERS] Proposal for async support in libpq

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-04-20T17:58:19Z

    > 
> No, I have no problem with getting a regular packet from the backend
> when the notify condition occurs.  What I don't like is creating excess
> network traffic above and beyond the notification packet --- especially
> not having to "poll" continuously to see whether the condition has
> occurred.  But using select() to wait for something to happen does not
> induce network traffic.

Got it.  I guess I suspected that you would not necessarily be in a
select() call at all times.  If you are waiting for user input, or using
libpq and your app is waiting for some keyboard input, you really are
not hanging waiting for input from the backend, are you?

> 
> The only advantage of sending outgoing notifications as OOB is the fact
> that a SIGURG signal gets delivered to the recipient, which could be
> used to trigger abandonment of some current operation.  But I have a
> hard time perceiving where a client would want that, as opposed to
> detecting the notify after it completes whatever it's currently doing.
> 
> Sending cancellation requests inbound to the server is exactly what OOB
> is for, because there you must interrupt current processing to get the
> desired result.  Outbound notify signals are a different thing IMHO.
> An SQL NOTIFY is typically going to trigger new processing in the
> client, not cancel an operation in progress.
> 
> There are positive reasons *not* to force applications to handle
> notifies as OOB data, primarily having to do with portability and risk
> of breaking things.  For example, consider a frontend app that already
> deals with OOB/SIGURG on a different input channel.  If libpq takes over
> SIGURG signal handling, we break the app.  If not, we probably still
> break the app, because its signal handling logic is likely expecting
> SIGURG only from the other channel.
> 
> In short, inbound OOB to the server is OK because we have control of
> everything that will be affected.  Outbound OOB is not OK because
> we don't.
> 
> > One issue raised
> > by Stevens' "Unix Network Programming"(p. 333) is that the OOB
> > signal(SIGURG) can arrive before the data is ready to be read.
> 
> Right.  One advantage of using OOB only for cancel is that the SIGURG
> signal itself is the interesting event; you don't really *need* to get
> the OOB data to know what to do.  You can read and discard the OOB data
> at any convenient point, perhaps just before trying to read normal data
> from the client channel.
> 
> 			regards, tom lane
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)