Re: Win32 signal code - first try

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

Browse pgsql-hackers-win32 by date

  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