On Sun, 23 Oct 2005, Tom Lane wrote:

> "Magnus Hagander" <mha@sollentuna.net> writes:
>
> In the spirit of incremental improvement ... I've taken Magnus' version
> and added the proposed change to re-enable Qingqing's patch by skipping
> WaitForSingleObjectEx altogether in the CHECK_FOR_INTERRUPTS code path.
> I also removed WaitForSingleObjectEx in pgwin32_poll_signals(), which
> AFAICS should be just like CHECK_FOR_INTERRUPTS. I think this is what
> we are proposing to actually apply to 8.1beta4. I can't test it though,
> so please check it over...
>
Questions:

Are we asserting that

UNBLOCKED_SIGNAL_QUEUE() != 0
then
WaitForSingleObjectEx(0)==WAIT_OBJECT_0

If so, we can put this assertion in. Seems there is some race. In
pg_queue_signal(), we do it like this:

enter_critical_section();
mask the signal;
leave_critical_section();
SetEvent();

That is, we may detect the value first before we got event. So at least
the above assertion is not correct. This may cause other problems, just
for a quick feedback.

Regards,
Qingqing


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Qingqing Zhou <zhouqq@cs.toronto.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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend