Re: Machine sleep & wake notifications in a daemon
Re: Machine sleep & wake notifications in a daemon
- Subject: Re: Machine sleep & wake notifications in a daemon
- From: Andrew Keller <email@hidden>
- Date: Mon, 12 Jan 2015 11:30:47 -0500
On Jan 8, 2015, at 7:00 PM, Andrew Keller <email@hidden> wrote:
> On Jan 8, 2015, at 6:11 PM, Greg Parker <email@hidden> wrote:
>
>> On Jan 8, 2015, at 2:54 PM, Andrew Keller <email@hidden> wrote:
>>
>>> On Jan 8, 2015, at 5:20 PM, Ken Thomases <email@hidden> wrote:
>>>
>>>> On Jan 8, 2015, at 4:03 PM, Andrew Keller <email@hidden> wrote:
>>>>
>>>>> I would like to receive machine sleep and wake notifications in my daemon. In my Cocoa GUI application, I was able to easily follow the sample code under Listing 1 on the page <https://developer.apple.com/library/mac/qa/qa1340/_index.html>, but when I tried the same approach in my daemon, I received no errors or warnings from Xcode or in the system console, and yet the handlers also did not fire. After poking around for a while, I have a hunch that it may have something to do with the main event queue not being the same (or existing at all?) in a non-Cocoa GUI application.
>>>>>
>>>>> Is it possible to have a Cocoa-style event queue in a daemon, or is there another way to receive machine sleep and wake notifications from the OS in a daemon?
>>>>
>>>> Did you read further down that QA article you linked to listings 3 and 4?
>>>
>>> Yes. It looks very promising, but on the first try, I wasn't able to keep the run loop running (it exited immediately). I suspect that the problem has to do with the run loop not having any input sources. I'm currently in the middle of <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html>, where it's explaining how to create run loop sources. I'm learning quite a lot here, but that also means that progress is very slow at the moment. I figured it would hurt to ping the list to see if there was a simpler solution or perhaps documentation more specialized to my objective.
>>>
>>> Also, I have a feeling that there may be something missing conceptually. Suppose I do manage to keep the run loop running using a new input source. How do the OS and the application frameworks know to route the notification there? I suspect that some additional object registration may be needed to make the run loop handle the events, or it might be a very specific input source I don't know about yet...
>>
>> You shouldn't need to write your own run loop source implementation. QA1340's sample code shows how it works. IORegisterForSystemPower() creates an IONotificationPort that receives power notifications. IONotificationPortGetRunLoopSource() creates a run loop source from that notification port. CFRunLoopAddSource() adds that run loop source to the run loop. Notifications sent by the OS are routed to that run loop, and when you run that run loop it calls your callback function with those notifications.
>>
>> You should double-check that your code is arranged the same way as QA1340's code. You should also check for errors from any of those functions; perhaps the notification port or run loop source is not created for some reason.
>
> Ah! Looks like I was being too methodical; I didn't look ahead to where the port is created. (I didn't copy and paste all of the example at once; I was attempting to do it incrementally.)
>
> Thanks, Ken and Greg; I'll try that when I get into work tomorrow.
Thanks again; everything works as expected.
One last question: Is there anything bad about using this code in a Cocoa application, assuming you correctly guarantee that the new run loop is not running on the main thread?
Thanks,
- Andrew Keller
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden