[reviving this at great personal risk on win32]
> 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
> > 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.
How are we going to work around this issue?
ISTM we have four options:
(a) Finding out for sure whether or not socket calls within APCs mash the
state of the internal socket libs etc. We (now) know that a socket call
within an APC will cause a currently blocked socket call to fail without
error, but is anything else hammered that we don't (yet) know about? If we
can determine that the answer is no, we have a simple work-around (ie.
setting a flag like APCcalled, and checking on return from select...)
(b) Another win32 work-around (like pushing the pgstat_send call out on a
separate thread, if allowed)
(c) Deferring the pgstat_beterm call
(d) Rewriting the win32 signal code
Ok. So we really have (at most) three options :-)
Is (c) out of the question? And, regardless of the answer to this, does
anyone have a definitive answer to (a), or what might be allowed in (b)?
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
pgsql-hackers-win32 by date
|Next:||From: Mohan||Date: 2004-03-17 07:25:54|
|Subject: Storage Architecture!|
|Previous:||From: Claudio Natoli||Date: 2004-03-17 06:17:09|
|Subject: Re: shutdown problems on win32|