Skip site navigation (1) Skip section navigation (2)

Re: Patch for select and APC on win32

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander' <mha(at)sollentuna(dot)net>,Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for select and APC on win32
Date: 2004-03-23 13:13:24
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F3AC@harris.memetrics.local (view raw or flat)
Thread:
Lists: pgsql-patches
> > > Here's a patch implementing the "thread method" to 
> > workaround the bug 
> > > with socket calls in signal handlers. See details in mail to 
> > > pgsql-hackers-win32 a couple of minutes ago.
> > 
> > Looks ok, but wouldn't it be better placed in pgstat.c?
> 
> Actually, I don't think so. I considered it, and chose to put it in
> postmaster.c for the following reason:
> 
> The functon pgstat_beterm itself is *not* the problem. In theory, it can
> be called from places that are not signal handlers (sure, it's not done
> today I think, but internal-API-wise, it could). That goes against
> putting the fix ther.

Sure, like I said, my 2c. Just looks a little out of place. Understand point
on API, but think it is clear that this isn't a win32 replacement for
pgstat_beterm, but a win32 replacement for pgstat_beterm *called from a
signal handler* (perhaps a function name change would make it this clearer).

In any case, not fussed.

What I am wondering about now, is where else we need to change? AFAICS,
there is (at least?) one signal handler that performs sockets ops, namely
Async_NotifyHandler.

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>

pgsql-patches by date

Next:From: Claudio NatoliDate: 2004-03-23 13:16:05
Subject: Re: [pgsql-hackers-win32] win32 open patch for held unlink
Previous:From: Karel ZakDate: 2004-03-23 10:10:52
Subject: Re: pstrndup()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group