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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
