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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
  • 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 16:41:14 -0400
  • Message-id: <22224(dot)1130100074(at)sss(dot)pgh(dot)pa(dot)us>

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> 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".

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group