From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgkill on win32 |
Date: | 2008-04-22 07:56:08 |
Message-ID: | 20080422095608.346eaf46@mha-laptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2008-04-22 08:02:44 | Re: MERGE Specification |
Previous Message | Magnus Hagander | 2008-04-22 07:54:35 | Re: pgkill on win32 |