Re: SIGPIPE handling

Here is my solution to ignoring SIGPIPE in libpq's send() for threaded
apps.

It defines a custom SIGPIPE handler if one is not already defined by the
application, and uses a thread-local variable that is checked in the
SIGPIPE handler to know if the SIGPIPE was caused by a libpq send()
call.

The documentation is at the top of the patch. Changed from the
description below is that applications can define their own SIGPIPE
handler after establishing the first database connection. However,
custom SIGPIPE handlers must check PQinSend() to determine if the signal
should be ignored.

---------------------------------------------------------------------------

pgman wrote:
>
> Attached is my idea for implementing safe SIGPIPE in threaded apps. The
> code has the same libpq behavior if not compiled using
> --enable-thread-safety.
>
> If compiled with that option, an app wanting to define its own SIGPIPE
> handler has to do so before connecting to a database. On first
> connection, the code checks to see if there is a SIGPIPE handler, and if
> not, installs its own, and creates a thread-local variable. Then, on
> each send(), it sets, calls send(), then clears the thread-local
> variable. The SIGPIPE handler checks the thread-local variable and
> either ignores or exits depending on whether it was in send().
>
> Right now the thread-local variable is static to the file, but we could
> export it as a boolean so custom SIGPIPE handlers could check it and
> take action or ignore the signal just like our code. Not sure if that
> is a good idea or not. In fact, even cleaner, we could create a
> function that allows users to define their own SIGPIPE handler and it
> would be called only when not called by libpq send(), and it would work
> safely for threaded apps.
>
> I think the big problem with my approach is that it requires special
> custom SIGPIPE handler code even if the app isn't multi-threaded but
> libpq is compiled as multi-threaded.
>
> Another idea is to create PQsigpipefromsend() that returns true/false
> depending on whether the SIGPIPE was from libpq's send(). It could be a
> global variable set/cleared in non-threaded libpq and a thread-local
> variable in threaded libpq. It would allow the same API/behavior for
> both libpq versions and all custom SIGPIPE handlers using libpq would
> have to check it.
>
> The one good thing about the patch is that it ignores send() SIGPIPE,
> and gives default SIG_DFL behavior for libpq apps with no special app
> coding, with the downside of requiring extra cost for custom SIGPIPE
> handlers.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073