This is a discussion on Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance within the pgsql Hackers forums, part of the PostgreSQL category; --> > > But. in theory, we can get a false positive from > > UNBLOCKED_SIGNAL_QUEUE(), right? > > We ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| > > 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |