Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch applied.  I also documented an optimmization we might make
> > leter in fe-secure.c:
> >         n = send(conn->sock, ptr, len, 0);
> >         /*
> >          *  Possible optimization:  if sigpending() turns out to be an
> >          *  expensive operation, we can set sigpipe_pending = 'true'
> >          *  here if errno != EPIPE, avoiding a sigpending call.
> >          */
> I went ahead and did that (or a cleaner equivalent) because I think it's
> important that we not risk clearing events we shouldn't clear.  In the
> normal path where we don't get EPIPE, it's now certain that secure_write
> won't have any side effects on the application state; saving a kernel
> call is a free bonus.  The fe-print.c code is a bit more problematic
> but I tend to think it's vestigial anyway.


> Per our phone discussion this morning, this code should be solid except
> in the case where the C library is able to queue multiple pending
> SIGPIPE events.  Like you, I'm dubious that that exists in the real
> world, or that anybody could cope with it if it did.  (Example: if
> someone blocks SIGPIPE and calls a complex function like fprintf(), how
> could he be certain that only one SIGPIPE event had been queued before
> it returned?)

Great.  Right now the code path is only two pthread_sigmask() calls. 
That has got to be quite fast, I bet.

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to