Re: socket calls in signal handler (WAS: APC + socket r

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>, <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: socket calls in signal handler (WAS: APC + socket r
Date: 2004-03-17 08:15:38
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34B4E0@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-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
> 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.
>
> 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...)

I'm working on this one. I have a case open with Microsoft on it.
ATM the workaround appears to be working for me - will try it with this
specific case as well. Bu I'm not yet sure how safe it it.

> (b) Another win32 work-around (like pushing the pgstat_send
> call out on a separate thread, if allowed)

That could be a workable workaround. The weird thing is, AFAIK the
socket functinos are *thread safe*, but apparantly not *APC safe*.

> (c) Deferring the pgstat_beterm call

This is the one that affects other platforms, so we should stay clear of
it if possible.

> and, ah:
> (d) Rewriting the win32 signal code

Yikes! :-)
But really, there is an option for this built into the code design
already. We can stop using APCs for it, and just put PG_POLL_SIGNALS (I
think it was called - code not around ATM) after every place where we
ahve an alertable wait. Not pretty, but can be done.

> 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)?

I'm working on getting (a). Depending on the answer of (a), I will force
an answer out of MS about (b). Only if these fails we should chose
between (c) and (d) (affecting main code base vs uglyfying the win32
signals code further).

So I'd recommend waiting for the outcome of (a) before making a final
decision. That still seems the least hackish solution.

//Magnus

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Mohan 2004-03-17 12:41:54 PostgreSQL Storage Architecture
Previous Message Mohan 2004-03-17 07:25:54 Storage Architecture!