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.
>
>
>
