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

Re: [HACKERS] [PATCHES] fork/exec patch

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Steve Tibbett" <stibbett(at)zim(dot)biz>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>,"Magnus Hagander" <mha(at)sollentuna(dot)net>,"Andrew Dunstan" <andrew(at)dunslane(dot)net>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-16 21:04:07
Message-ID: 303E00EBDD07B943924382E153890E5434AA30@cuthbert.rcsinc.local (view raw or whole thread)
Lists: pgsql-hackers-win32
Steve Tibbett wrote:
> Ah I see what you're saying, the polling isn't the
> it's that the main thread that's going to have to poll something to
> if the thread that's doing the WaitForSingleObject has woken up and
> a signal or something.

QueueUserAPCEx is perfect: it provides all the niceties of signaling
without having to deal with 'polling' (main thread state checking),
timeouts, loops, or any other such things.  In fact, this will fit
perfectly with the pipes implementation i.e. thread startup upon signal
action, alter main backend thread, execute signal action (in main thread
context), drop thread, with near instantaneous response.  Looking at it
from the top down, this is a 'push' not a 'pull' model.

Also, this does not rely on generating an access violation, which would
implementation of normal thread signaling (i/o completion ports) in the
future more difficult.  Assuming the implementation is robust,
QueueUserAPCEx suits postgres perfectly.

What license is QueueUserAPCEx distributed under? :)  Is there any
security or usability issues regarding installation of a kernel mode


pgsql-hackers-win32 by date

Next:From: Steve TibbettDate: 2003-12-16 21:29:43
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Steve TibbettDate: 2003-12-16 20:48:14
Subject: Re: [HACKERS] [PATCHES] fork/exec patch

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