Re: APC + socket restrictions under Win32?

> >Is anyone aware of any restrictions in what can be called
> >within an APC,
> >such as we queue for signal handling. Specifically, are there any
> >restrictions related to socket calls?
>
> None that I know of. The documentation doesn't list any. And remember
> that such basic functinos as WriteFileEx and friends use APCs - and
> there is no mention of sockets being affected by that.
>
> I've used them in sockets based applications several times without any
> issues, but it might be that this is a border case somewhere.

You'll have to explain the attached code to me then...

As submitted:
* main thread creates a thread which will queue an APC in a couple seconds
* main thread enters a waiting (read) select on port 54321
* APC runs in main thread, and returns to waiting in select

All good. You can even telnet to port 54321, the select() will return (and
the app will exit) as you'd expect.

Now change the #if 0 to include the fd = socket(...) call, and
recompile/run. After the APC now runs, the select() returns, without error,
and with the socket mask FD_SET. WTF? Doing any socket ops in an APC causes
a waiting select() to return? Even just creating a socket?

FWIW, I've tried this under ming and VC++ with the same results.

As I'm finding this pretty hard to digest, I'm pretty willing to accept that
I've missed something, or that we are just missing a call to pre-condition
the system for this occurence...

[Speaking of documentation, I seem to be unable to find a lot of detail. For
instance, where does it say that select() causes the thread to enter an
alertable state? Clearly, it does, but I can't see where this is
documented.]

> >I've fixed the code for pgstat processes under Win32 on my
> >source base, and
> >am now seeing behaviour which, afaics, can only be explained
> >by failing to
> >adhere to such a restriction.
>
> Haven't looked at the details of this problem yet - can you
> elaborate a bit on what you're seeing?
> (And what did you have to fix?)

This'll be easier to detail when I've sent through a patch for pgstat (which
is quite busted under win32 right now), but basically the pgstat_send call
(invoked via a pgstat_beterm call as a result of SIGCHLD, handled via APC),
in making a socket call, seems to cause the select (which we were waiting in
on unrelated sockets in ServerLoop) to return, without error, and with the
socket masks FD_SET (which then gets us into a premature accept call, and
then...). [After a considerable period of debugging, found that commenting
out the pgstat_send call stopped the postmaster crashing! To say I was
surprised is something of an understatement]

To fix? Well, a kludge which worked was to fire off a thread to do the
pgstat_send call. [A better (hmmm) solution would be to retry the select on
each socket when FD_SET is true, but using a zero timeout... assuming, of
course, that a "polling" select doesn't suffer from the same problem]

As assumed above, this probably isn't very clear, so I'll get the pgstat
changes submitted shortly. For now, let's stick with the attached example. I
think it demonstrates the problem clearly enough (unless I'm seriously
missing something).

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>