From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Magnus Hagander " <mha(at)sollentuna(dot)net> |
Subject: | Re: [pgsql-hackers-win32] Win32 signal code - first try |
Date: | 2004-01-13 14:54:13 |
Message-ID: | 303E00EBDD07B943924382E153890E5434AA51@cuthbert.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-13 14:54:23 | Re: LWLock/ShmemIndex startup question |
Previous Message | Hannu Krosing | 2004-01-13 12:42:41 | Re: Encoding problems in PostgreSQL with XML data |