From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jimmy Yih <jyih(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket |
Date: | 2018-07-19 20:38:11 |
Message-ID: | 20180719203810.GO9712@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 19, 2018 at 01:35:02PM -0700, Andres Freund wrote:
> On 2018-07-19 15:17:26 -0500, Nico Williams wrote:
> > You can create that thread with a really small stack given that its only
> > purpose is to do this error reporting and exit.
>
> You still have a full kernel process backing it, which is *FAR* from
> free. [...]
It's not that big. Its stack is small.
> [...] And we'd enough infrastructure to setup threads with small stacks
> on a number of platforms.
Portability is actually the problem here, yes. But you could enable the
async-signal-safe thread path in some platforms and not others, and
you'd still be improving things.
> > Running a thread that does only this does not impact the rest of the
> > code in the backend at all -- it's not "threading" the backend.
>
> It actually does. Without passing thread related flags to the compiler,
> which you need to do for correctness, the compiler and libraries are
> free to use faster non-threadsafe implementations.
That's build goop, but there's no need to add mutexes or whatever
elsewhere.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-07-19 20:38:52 | Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket |
Previous Message | Andres Freund | 2018-07-19 20:36:45 | Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket |