Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Jul 2, 2020 at 6:39 PM James Sewell <james.sewell@jirotech.com> wrote:
>> The patch replaces sigprocmask with pthread_sigmask. They have identical APIs ("[pthread_sigmask] shall be
equivalentto sigprocmask(), without the restriction that the call be made in a single-threaded process"[1])
> -#define PG_SETMASK(mask) sigprocmask(SIG_SETMASK, mask, NULL)
> +#define PG_SETMASK(mask) pthread_sigmask(SIG_SETMASK, mask, NULL)
> So you're assuming that <signal.h> declares pthread_sigmask().
If we were going to accept this patch, I'd say it should be conditional
on a configure test for pthread_sigmask being present. We could allow
that to require an additional library, or not.
>> The rationale here is that as far as I can tell this is the *only* blocker to using multithreaded code in a BGWorker
whichcan't be avoided by adhering to strict code rules (eg: no PG calls from non-main threads, no interaction with
signalsfrom non-main threads).
TBH, though, I do not buy this argument for a millisecond. I don't
think that anything is going to come out of multithreading a bgworker
but blood and tears. Perhaps someday we'll make a major push to
make the backend code (somewhat(?)) thread safe ... but I'm not on
board with making one-line-at-a-time changes in hopes of getting
partway there. We need some kind of concrete plan for what is a
usable amount of functionality and what has to be done to get it.
regards, tom lane