From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Win32 signal code - first try |
Date: | 2004-01-08 21:08:19 |
Message-ID: | 303E00EBDD07B943924382E153890E5434AA40@cuthbert.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
> Here is a first sketch at Win32 signal handling. First a couple of
> comments:
Couple of quick questions/points regarding your implementation:
1. Fully support your decision to use named pipes.
2. __pg_signal_count is guarded by a CriticalSection. Are
Interlocked{Exchange / Increment} still necessary?
3. you are absolutely certain that
__pg_poll_signals() +
EnterCriticalSection +
memset +
if... +
LeaveCriticalSection +
if...
is more efficient than a single call to WaitForSingleObjectEx() with 0
timeout?
> * Uses named pipes. Shared mem was slightly faster, named pipes a lot
> cleaner. And the signal handlers themselves should not be performance
> critical, AFAICS.
Right...only the 'poll' function is truly critical
> * Does *not* use user APCs. Why? Well, we had to use polling. And with
> user APCs we'd have to go into kernel mode (however briefly) on every
> poll. I replaced that with a simple counter that is checked. Thast way
> we don't slow down the main path of the program much.
Have you have given up on using a kernel mode driver to throw a thread
into alertable state?
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-01-08 21:27:58 | Re: Win32 signal code - first try |
Previous Message | Magnus Hagander | 2004-01-08 20:27:24 | Win32 signal code - first try |