Re: pgkill on win32 - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pgkill on win32
Date
Msg-id 20080422095608.346eaf46@mha-laptop
Whole thread Raw
In response to Re: pgkill on win32  (James Mansion <james@mansionfamily.plus.com>)
Responses Re: pgkill on win32  (James Mansion <james@mansionfamily.plus.com>)
List pgsql-hackers
James Mansion wrote:
> Magnus Hagander wrote:
> > The problem is when winsock operations are interrupted by APCs. 
> >
> > See:
> > http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
> >   
> Whoa! Indeed, that's a bit sucky because they really aren't
> documented as interruptible.
> 
> In this case though I see not material problem with going back to
> APCs. At the moment you
> deliver to a pipe server thread with a pipe RPC.  I can't see why you 
> cannot deliver to a
> signal handling thread with the APC - the published
> {thread-id,function} tuple does not need
> to refer to the main thread for the process. This would
> de-synchronize the delivery but make
> a relatively small change since that background thread could deliver
> to the main thread the
> same way it does now.

Good point. I see no reason not to be able to do that, agreed. Once we
accepted using a second thread for it, that opportunity is certainly
there.

You interested in trying to code up a patch to verify that? ;)


> If there were any desire to provide a MT-aware postmaster, the same 
> technique of masking
> signals except on a signal thread might apply.

Define MT-aware :-) It's certainly MT-aware in the fact that it's
already MT... But there is no interest in making the actual backends
launch as threads in the postmaster - at least not currently.

//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pgkill on win32
Next
From: Martijn van Oosterhout
Date:
Subject: Re: MERGE Specification