Claudio Natoli wrote:
> FWIW, in a multithreaded version of postgres I'm fooling around with,
I
> replaced the recv call (where backends spend most of their time
waiting)
> which a select(small timeout)/SleepEx(0) "busy" loop, which calls to
recv
> when ready. Works just fine.

Ok, that makes perfect sense.  Simply checking pending signals in this
loop and just after a command is received will catch most of them, and
provide a suitable testing platform.

IMO, it's time for a second run of the code, and a functional test which
simulates the command processing loop which should include:

1. setjmp/longjmp stack manipulation (i.e. ELOG)
2. in process/out of process generates signals
3. all thread mechanisms.

under heavy load conditions.
We should be especially watching for deadlocks, stack corruption, and
memory leaks...    If everything goes ok, I think we'll have a good
'proof of concept' signaling mechanism.  After that, its time to start
submitting patches to the hackers for review...

Merlin


Tue, 13 Jan 2004 09:54:13 -0500
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: [pgsql-hackers-win32] Win32 signal code - first try