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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

Steve Tibbett wrote:
> Ah I see what you're saying, the polling isn't the
WaitForSingleObject,
> it's that the main thread that's going to have to poll something to
see
> if the thread that's doing the WaitForSingleObject has woken up and
set
> 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
driver?

Merlin

Browse pgsql-hackers-win32 by date

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