On Jan 8, 2015, at 7:00 PM, Andrew Keller <and...@kellerfarm.com> wrote:
> On Jan 8, 2015, at 6:11 PM, Greg Parker <gpar...@apple.com> wrote: > >> On Jan 8, 2015, at 2:54 PM, Andrew Keller <and...@kellerfarm.com> wrote: >> >>> On Jan 8, 2015, at 5:20 PM, Ken Thomases <k...@codeweavers.com> wrote: >>> >>>> On Jan 8, 2015, at 4:03 PM, Andrew Keller <and...@kellerfarm.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
