Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance |
Дата | |
Msg-id | 435AE7CB.9060008@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance (Qingqing Zhou <zhouqq@cs.toronto.edu>) |
Ответы |
Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
|
Список | pgsql-hackers |
Well, first, have you tested it with "make check"? I am not sure if there's any great value in supporting a non null old value param. Second, please note that the PostgreSQL community convention is for patches as context diffs, not unidiffs. I guess there are several ways to skin this cat - the way I had sort of worked out reading the MSDN docs was to call QueueUserAPC on the timer thread. I'd like to know what Magnus and Merlin especially think out it. cheers andrew Qingqing Zhou wrote: >>Andrew Dunstan <andrew@dunslane.net> writes: >> >> >>>The hard part looks to be cancelling/changing the timer, which means >>>that we can't just create a set and forget listener thread for a given >>>timeout. Otherwise that seems to me the straightforward approach. >>> >>> >>Yeah. I think probably the cleanest way is to create a persistent >>thread that manages the timer. We need a way for the main thread to >>tell it to cancel the timer or change the setting. Dunno enough about >>Windows' interthread communication primitives to propose details. >> >> >> > >Oh my ... fortunately we got a timer test in regression. > >I've come up with a quick patch implementing above discussions. Also, >seems by patching this, we can support setitimer(.,.,ovalue != NULL) -- >because it is saved in the memory. > > >
В списке pgsql-hackers по дате отправления: