Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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 +

is more efficient than a single call to WaitForSingleObjectEx() with 0

> * 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?


pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2004-01-08 21:27:58
Subject: Re: Win32 signal code - first try
Previous:From: Magnus HaganderDate: 2004-01-08 20:27:24
Subject: Win32 signal code - first try

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group