From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:33:06 |
Message-ID: | Pine.LNX.4.58.0510231626030.17114@josh.db |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 23 Oct 2005, Magnus Hagander wrote:
>
> But. in theory, we can get a false positive from
> UNBLOCKED_SIGNAL_QUEUE(), right? Since we do it unlocked between two
> threads. If we do that, we'll "recover" in dispatch_signals, because
> we'l lcheck again locked and not dispatch any signals. *but*. If this
> happens, we will return EINTR even when there is no signal. That doesn't
> seem correct to me. It's a very small window, but it should be possible,
> no?
>
> We probably need an actual check, so for example have
> dispatch_queued_signals return a value indicating if any signals were
> actually dispatched, and use that to control EINTR?
>
> Comments? Or am I completely off being too tired right now? ;-)
>
You are not. Basically that's what I just sent an email about :-) Since
signals are not quite often happened, so I am thinking just adding a
UNBLOCKED_SIGNAL_QUEUE() is more safe maybe for now.
Regards,
Qingqing
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-10-23 20:34:10 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
Previous Message | Qingqing Zhou | 2005-10-23 20:22:26 | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |