| 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: | 2005-10-23 20:56:10 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE92E794@algol.sollentuna.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-10-24 00:21:44 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
| Previous Message | Tom Lane | 2005-10-23 20:45:04 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |