16114f2ea0
Since its inception, our Windows signal emulation code has worked by running a main signal thread that just watches for incoming signal requests, and then spawns a new thread to handle each such request. That design is meant for servers in which requests can take substantial effort to process, and it's worth parallelizing the handling of requests. But those assumptions are just bogus for our signal code. It's not much more than pg_queue_signal(), which is cheap and can't parallelize at all, plus we don't really expect lots of signals to arrive at the same backend at once. More importantly, this approach creates failure modes that we could do without: either inability to spawn a new thread or inability to create a new pipe handle will risk loss of signals. Hence, dispense with the separate per-signal threads and just service each request in-line in the main signal thread. This should be a bit faster (for the normal case of one signal at a time) as well as more robust. Patch by me; thanks to Andrew Dunstan for testing and Amit Kapila for review. Discussion: https://postgr.es/m/4412.1575748586@sss.pgh.pa.us |
||
|---|---|---|
| .. | ||
| aix | ||
| hpux | ||
| tas | ||
| win32 | ||
| .gitignore | ||
| Makefile | ||
| atomics.c | ||
| posix_sema.c | ||
| sysv_sema.c | ||
| sysv_shmem.c | ||
| win32_sema.c | ||
| win32_shmem.c | ||