Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi,

On 2018-07-19 15:27:06 -0500, Nico Williams wrote:
> No, the other thread does NOT continue to do whatever -- it
> blocks/sleeps forever waiting for the coming exit(3).
>
> I.e., quickdie() would look like this:
>
> /* Marshall info in to an automatic */
> struct quickdie_info info, *infop;
>
> info.this = that;
> ...
> infop = &info;
>
> /* Tell the death thread to report and exit */
> /* XXX actually something like net_write(), to handle EINTR */
> write(quickdie_pipe[1], infop, sizeof(infop));
>
> /* Wait forever */
> for (;;) usleep(FOREVER);
>
> and the thread would basically do:
>
> struct quickdie_info *info;
>
> /* Wait forever for a quickdie() to happen on the main thread */
> /* XXX Actually something like net_read(), to handle EINTR */
> read(quickdie_pipe[0], &infop, sizeof(infop));
>
> ereport(infop->...);
>
> exit(1);
>
> This use of threads does not require any changes to the rest of the
> codebase.

Uhm, this'd already require a fair bit of threadsafety. Like at least
all of the memory allocator / context code. Nor is having threads
around unproblematic for subprocesses that are forked off. Nor does
this account for the portability work.

Greetings,

Andres Freund