Re: [HACKERS] Proposal for async support in libpq - Mailing list pgsql-hackers

>
> 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)