Re: Xsync alarm implementation
Re: Xsync alarm implementation
- Subject: Re: Xsync alarm implementation
- From: Jeremy Sequoia <email@hidden>
- Date: Thu, 19 Nov 2015 11:42:06 -0800
Sent from my iPhone...
>> On Nov 19, 2015, at 11:29, René J.V. Bertin <email@hidden> wrote:
>>
>> On Thursday November 19 2015 10:26:59 Jeremy Huddleston Sequoia wrote:
>>
>> If you want a way to cancel it, you should use a timer source and then cancel the timer. Using a timer source is probably more appropriate than dispatch_after but is less obvious in usage, so I didn't mention it.
>
> Ah, are those the "sources" mentioned in the CFRunLoopObserver reference doc? Searching the API docs for just "sources" gave too many irrelevant hits, maybe that "timer source" is going to be specific enough.
Look at dispatch/source.h or https://developer.apple.com/library/mac/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html#//apple_ref/doc/uid/TP40008091-CH102-SW1
>
>> Eg: Assume you want to know when the system has been idle for 10 minutes, you'll schedule the block to run in (10_minutes - current_idle_time). When the block runs, you check the current idle time. If it's over 10 minutes, great. If it's not, reschedule that block for (10_minutes - current_idle_time).
>
> Yeah, that's what I began to figure typing my previous reply. The discussion about this elsewhere had become so centred around a "don't ever poll" principle that I never realised that I no longer needed to check early now that I have an event filter to reset the mechanism if a user event comes in to end the idle period.
> If the user is still idle when I check at the scheduled time, all I have to do is either call it a day, or schedule a check at the next configured timeout.
>
> Thanks for confirming that, it was exactly the kind of constructive feedback I should have gotten elsewhere.
>
>> If you want the ability to change the timeout, cancel it, etc, you definitely would wan to use a timer source.
>
> The question is what's easier and above all less CPU/battery unfriendly: check HIDIdleTime when the dispatch occurs and do nothing with the value if it's inferior to the programmed value, or cancel the scheduled check.
>
> R
I don't quite follow. I suppose the two options are:
1) reschedule the timer every time you get an event
2) record the event time when you receive an event and reschedule the timer in the handler whenever it fires.
#1 is more expensive on each event.
#2 seems cheaper to me, especially if your idle time is in the range of multiple minutes.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden