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. >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 _______________________________________________ Do not post admin requests to the list. They will be ignored. X11-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com This email sent to [email protected]
