Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
- To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>
- Subject: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- Date: Sun, 23 Oct 2005 22:56:10 +0200
- Message-id: <6BCB9D8A16AC4241919521715F4D8BCE92E794(at)algol(dot)sollentuna(dot)se>
> > But. in theory, we can get a false positive from > > UNBLOCKED_SIGNAL_QUEUE(), right? > > We could have gotten a false positive from the old coding, too. > The event was certainly not any more tightly tied to the > presence of an unserviced signal flag than > UNBLOCKED_SIGNAL_QUEUE, and arguably less so. > > I think this concern is irrelevant anyway. Returning EINTR from > select() is OK even if no signal was actually serviced, so > long as it doesn't recur indefinitely. EINTR just means "I > didn't do the select(), try again". Ok. I don't see any way why it would recur indefinitly, since we'll clean it up in the dispatch routine. And any half-updated-value will be fully updated a *very* short time later. So we sohuld be fine. //Magnus
- Prev by Date: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- Next by Date: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- Previous by thread: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- Next by thread: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
- Indexes: