On Thu, Jul 19, 2018 at 01:10:14PM -0700, Andres Freund wrote: > On 2018-07-19 15:04:15 -0500, Nico Williams wrote: > > Besides making ereport() async-signal-safe, which is tricky, you could > > write(2) the arguments to a pipe that another thread in the same process > > is reading from and which will then call ereport() and exit(3). This > > would be less work if you're willing to use a thread for that (the > > thread would only block in read(2) on that pipe, and would only provide > > this one service). > > It'd also increase memory usage noticably (we'd have twice the process > count in the kernel, would have a lot of additional stacks etc), would > tie us to supporting threading in the backend, ... This is a DOA > approach imo.
You can create that thread with a really small stack given that its only purpose is to do this error reporting and exit. 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. When it gets invoked, the caller would be blocking / sleeping, waiting for the coming exit, while this helper thread would block until invoked. It's really not a big deal. I use this technique in some of my programs (unfortunately none in my github repos). Usually I use it for detection of parent process death (so that if the parent dies silently, the children die too). In that case the child-side of fork() closes the write end of a pipe and starts a thread that blocks in read(2) on the read end of the pipe, and exit()s when the read returns anything other than EINTR. Nico --