Re: pgkill on win32 - Mailing list pgsql-hackers

James Mansion wrote:
> Magnus Hagander wrote:
> > Yes. We used to use APCs, but touching anything remotely related to
> > Winsock from an APC is not supported... We had a lot of trouble
> > with it 
> By implication you'd be doing socket'y stuff from the signal handler
> on UNIX? Scary.

Uh, sorry, got that explained backwards.
The problem is when winsock operations are interrupted by APCs. 

See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php


> I was assuming it would be used to signal an event that would release 
> the main
> thread and then do the real work there.
> 
> I suppose by implication you can't knock a thread out of select from
> the APC?

Not only that, but you may corrupt internal winsock structures if you
try. 

As stated, one major issue is that we have third-party libs calling the
winsock functions directly (SSL and Kerberos come to mind - the GSSAPI
code specifically does not do this). For SSL, I'd like to eventually
rewrite it to make sure *we* call the send and receive functions and
just use the library to encrypt buffers, which should make things a
bit safer in that regard.


> I can help feeling that the eventselect mechanism is the one to use,
> not the crappy bsd select emulation.

The original design, which is what is there now, was written to make
sure we made as little change as possible to the backend code itself,
and instead implemented portability layers. I think now that the port
is more mature, if we need to make some smaller changes around say the
select loop processing, we can do that - as long as we're careful. But
we certainly don't want to do anything that'll require more or less
global changes around the code.


> > initially, and it took a long support case with Microsoft PSS to
> > figure out what was broken, because this being unsupported was not
> > properly documented.
> >   
> Indeed. And its a very odd limitation given the way that APCs are
> used with completion ports.
> Did any sort of reference get written to the knowledge base for this,
> do you know?

There was one written, AFIAK, but I don't remember the number or can't
find it right now. It may well be that it's premier only. Also, it only
applied to traditional sockets API calls, and not "native" Winsock2
calls. But see above about SSL.


> > It certainly is ;-) We could probably find something more efficient,
> > but APCs are not the one.
> >   
> The concern I have isn't so much that the mechanism might be a bit
> ugly, but the synchronous
> delivery and the scheduling gymnastics implied..

Right.

//Magnus