Re: Threading in BGWorkers (!)

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