Re: socket calls in signal handler (WAS: APC + socket r
If that is indeed the case, I withdraw all my comments and misdirected
ideas, and say we go for a win32 specific workaround :-)
We just need to be very careful on what this work-around is though...
For instance, whilst the idea of an "APCcalled" flag will work just fine,
mechanically, I'm extremely hesitant to adopt it until we *know* for sure
that, by making a socket call inside the APC, we aren't somehow munging
another part of the socket state. [after all, we didn't anticipate the
current issue]
Unfortunately, afaics, the MSDN documentation is pretty slim on details in
this regard.
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>Tom Lane wrote:
I don't like the idea of redesigning that
code just because someone misunderstands it.
Fair enough, on both counts. However, the original question which was asked
out of ignorance (that I'll freely admit) doesn't seem to have been directly
addressed:
Claudio Natoli wrote:
The specific (and possibly only? are their others?) issue is the call to
pgstat_beterm from reaper/CleanupProc, invoked by a SIGCHLD. Can this call
be deferred to the main loop (ie. ServerLoop) and is there any merit in
doing so?
Just canvassing for options. If we can get a win32 specific change that we
trust, great! (I think it goes without saying that, throughout the work on
this port, we've tried to avoid changing the existing code as much as
possible). However, if we can not, I'd like to have other options, and am
exploring this possibility.
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>Import Notes
Resolved by subject fallback