| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
| Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, 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:45:04 |
| Message-ID: | 22261.1130100304@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> Are we asserting that
> UNBLOCKED_SIGNAL_QUEUE() != 0
> then
> WaitForSingleObjectEx(0)==WAIT_OBJECT_0
No.
> If so, we can put this assertion in.
Only if you want it to crash every so often.
The "race condition" is that a signal delivered right about the time the
check is made may be serviced before the event is set, meaning that
after the dust settles the event will still be set when there's nothing
to do. This was true before, too, and will have no impact worse than
causing an extra entry to dispatch_signals later on.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2005-10-23 20:56:10 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
| Previous Message | Tom Lane | 2005-10-23 20:41:14 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |