Re: Threading in BGWorkers (!)

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Jul 2, 2020 at 6:39 PM James Sewell <james(dot)sewell(at)jirotech(dot)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