Re: [pgsql-hackers-win32] Win32 signal code - first try

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

Browse pgsql-hackers by date

  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