Thomas Munro <thomas.mu...@gmail.com> writes:
> On Thu, Jul 2, 2020 at 6:39 PM James Sewell <james.sew...@jirotech.com> wrote:
>> The patch replaces sigprocmask with pthread_sigmask. They have identical
>> APIs ("[pthread_sigmask] shall be equivalent to 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 which can't be avoided by adhering
>> to strict code rules (eg: no PG calls from non-main threads, no interaction
>> with signals from 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
