Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
От | Magnus Hagander |
---|---|
Тема | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE92E792@algol.sollentuna.se обсуждение исходный текст |
Ответы |
Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
Список | pgsql-hackers |
> > Here's another version of this patch ;-) I've based it on > your patch, > > so the changes to ovalue etc should sitill be there. > > 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... That does seem right. I think the only reason it was there i nthe first place was to deliver the APCs. 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? ;-) //Magnus
В списке pgsql-hackers по дате отправления: