August 2010 - Darwin-kernel

Re: Current active login session
by Quinn "The Eskimo!" 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 20 Aug 2010, at 14:02, Antoine Missout wrote: > It currently is 'not at all', but it seems I'll be forced to switch to 'as little as possible' to know the current active login, unless you can point me to something not well supported. Right. But what decisions does your daemon make based on the current active login? S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Antoine Missout 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com It currently is 'not at all', but it seems I'll be forced to switch to 'as little as possible' to know the current active login, unless you can point me to something not well supported. - Antoine On Aug 20, 2010, at 8:45 AM, Quinn The Eskimo! wrote: > > On 19 Aug 2010, at 23:56, Antoine Missout wrote: > >> That's what I planned to do if nothing else, but I would prefer to trust the agent as little as possible... > > Hmmm, I would've thought that your daemon should trust the agent "not at all", rather than "as little as possible". In general I prefer to set up systems like this so that, if the user tampers with their own agent, all they do is hurt themselves. What decisions are you making within your daemon based on this information? > >> If it was possible to get the answer in another manner directly from the daemon without relying on the agents, that'd be much better. > > Not in any well supported fashion. > > S+E > -- > Quinn "The Eskimo!" <http://www.apple.com/developer/> > Apple Developer Relations, Developer Technical Support, Core OS/Hardware > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/antoine.missout%40meta… > > This email sent to antoine.missout(a)metakine.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Quinn "The Eskimo!" 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 19 Aug 2010, at 23:56, Antoine Missout wrote: > That's what I planned to do if nothing else, but I would prefer to trust the agent as little as possible... Hmmm, I would've thought that your daemon should trust the agent "not at all", rather than "as little as possible". In general I prefer to set up systems like this so that, if the user tampers with their own agent, all they do is hurt themselves. What decisions are you making within your daemon based on this information? > If it was possible to get the answer in another manner directly from the daemon without relying on the agents, that'd be much better. Not in any well supported fashion. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
by Jerry Krinock 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 2010 Aug 20, at 01:28, Terry Lambert wrote: >> Why not have a timeout on the kevent… > > This is _a_ way, but your timeout would need to be tight to ensure that it was more or less responsive… Actually I could do that, since this is just to clean up resources; no hurry. But then there's that "elegance" thing. "Polling", anyone? Seems like it defeats the purpose of kqueue. > Alternately, the NSThread in 10.5.x is based on a pthread, so you could do: > volatile pthread_t kqueue_thread; > // called within the thread before looping > kqueue_thread = pthread_self(); Yes, this is one of your previous suggestions, to have the secondary thread feed back its thread ID. I kind of like your first suggestion better, to get the thread ID from pthread_create(). Warning: I've never done this – just reading docs. But I'll get it one way or the other. > // called before the close > // I picked SIGUSR1 … established a handler … sigaction(), without > // setting the SA_RESTART … the point is to cause kevent() to > // return -1 … with an [expected] errno … check … pthread_exit() normally. OK – so I see how killing can be done *professionally*. We're not just pulling the plug out of the wall. > There's no guarantee that future versions of NSThread will be based on the same primitives, but you can be pretty sure that there's not going to be a change in that regard in a 10.5.x, so as long as you check your OS version at runtime … Terry, I believe you're suggesting that I execute my current code for 10.6+, which relies on the fact that when I EV_DELETE a kqueue from the main thread, kevent() on the secondary thread returns -1 with errno=EINTR immediately. Certainly this is a very welcome new feature! But is it by design? Will it work in 10.7+? Where is it documented? If you're sure it's in there for keeps I shall happily file feedback to Apple on the documentation. Jerry > Technically, you could also subclass it as myNSThread so that you could access the tid member directly, and then add a method to kill it internally, but that's a lot of work for not a lot of benefit, since it's going to be 10.5 specific code anyway. Indeed, there's that "get the product out the door" thing. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to kill a camping kqueue thread? Was: close() hangs … in 10.5 only
by Terry Lambert 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 20, 2010, at 12:43 AM, Steve Checkoway wrote: > On Aug 19, 2010, at 22:56 , Jerry Krinock wrote: > >> >> Thank you, Terry. Fortunately for my feeble brain the problem was none of the rocket science you explained, just this one: >> >> On 2010 Aug 16, at 17:38, Terry Lambert wrote: >>> you have another thread camping out on the fd in kevent(). >> >> Indeed, my app operates by creating a kqueue in the main thread with kevent(…,EV_ADD|EV_ENABLE,…), and then spinning off a new thread via -[NSThread detachNewThreadSelector:::]. The new thread camps out on kevent() in a loop like this: > > Why not have a timeout on the kevent? If kevent returns with a timeout, then check some state (for exmaple the isCancelled method of NSThread) and exit if appropriate. Otherwise, loop. This is _a_ way, but your timeout would need to be tight to ensure that it was more or less responsive when you did the close. This would cause it to consume CPU cycles unnecessarily. I'm not sure how active the application is normally, so I have no idea if this would prevent power management, consume excessivle (relatively) CPU or could run opportunistically, etc.. Alternately, the NSThread in 10.5.x is based on a pthread, so you could do: ... // volatile global volatile pthread_t kqueue_thread; ... // called within the thread before looping kqueue_thread = pthread_self(); ... // called before the close // I picked SIGUSR1, but you could use any signal for which you've // established a handler, preferrably via sigaction(), without // setting the SA_RESTART flag; this assumes the signal is // otherwise unused; the point is to cause kevent() to return -1 // with an errno of EINTR, which you then check for when kevent() // returns and pthread_exit() normally. The signal will only go // to the specific thread. if (kqueue_thread) pthread_kill(kqueue_thread, SIGUSR1); There's no guarantee that future versions of NSThread will be based on the same primitives, but you can be pretty sure that there's not going to be a change in that regard in a 10.5.x, so as long as you check your OS version at runtime before using this method, you should be fine, and it should be immediately responsive. Technically, you could also subclass it as myNSThread so that you could access the tid member directly, and then add a method to kill it internally, but that's a lot of work for not a lot of benefit, since it's going to be 10.5 specific code anyway. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to kill a camping kqueue thread? Was: close() hangs … in 10.5 only
by Steve Checkoway 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 19, 2010, at 22:56 , Jerry Krinock wrote: -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Thank you, Terry. Fortunately for my feeble brain the problem was none of the rocket science you explained, just this one: On 2010 Aug 16, at 17:38, Terry Lambert wrote: you have another thread camping out on the fd in kevent(). Indeed, my app operates by creating a kqueue in the main thread with kevent(…,EV_ADD|EV_ENABLE,…), and then spinning off a new thread via -[NSThread detachNewThreadSelector:::]. The new thread camps out on kevent() in a loop like this: Why not have a timeout on the kevent? If kevent returns with a timeout, then check some state (for exmaple the isCancelled method of NSThread) and exit if appropriate. Otherwise, loop. smime.p7s

1 0

How to kill a camping kqueue thread? Was: close() hangs … in 10.5 only
by Jerry Krinock 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thank you, Terry. Fortunately for my feeble brain the problem was none of the rocket science you explained, just this one: On 2010 Aug 16, at 17:38, Terry Lambert wrote: > you have another thread camping out on the fd in kevent(). Indeed, my app operates by creating a kqueue in the main thread with kevent(…,EV_ADD|EV_ENABLE,…), and then spinning off a new thread via -[NSThread detachNewThreadSelector:::]. The new thread camps out on kevent() in a loop like this: while(true) { result = kevent(....) ; if (result != -1) { if(event.filter == EVFILT_VNODE) { // Filesystem event has occurred /* Create NSNotification */ /* Send NSNotification on main thread */ } } else { break ; } } // Thread exits return ; Now when my app is done with this kqueue, I delete it in the main thread with kevent(…,EV_DELETE|EV_DISABLE,…). When running in Mac OS 10.6, this causes kevent() in the secondary thread to return -1, which causes my secondary thread there to break out of its loop and exit. But when running in Mac OS 10.5, deleting the kqueue does *not* cause kevent() in the secondary thread to return. It just stays camped out. This 10.6 behavior of kevent(), to return -1 when its kqueue is deleted, does not seem to be documented. Maybe I discovered it by accident. So, the solution you suggested is to kill my camper thread. To do that I would need to rewrite using pthread_create() et al since NSThread has no equivalents to pthread_self() or pthread_kill() as far as I can see. But Apple's Threading Programming Guide recommends against killing threads. Many apps need to do other work while waiting for a filesystem event, and spinning off a camper thread seems natural. So, before re-coding with pthread_kill() I thought I'd ask if there is a better way to do this? Thank you, Jerry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Antoine Missout 19 Aug '10

19 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Quinn, That's what I planned to do if nothing else, but I would prefer to trust the agent as little as possible... If it was possible to get the answer in another manner directly from the daemon without relying on the agents, that'd be much better. - Antoine On Aug 19, 2010, at 4:56 PM, Quinn The Eskimo! wrote: > On 19 Aug 2010, at 21:09, Antoine Missout wrote: > >> What's the best way to do that ? > > Have the login agents tell you as they become active and inactive. > > Also, be prepared to have multiple agents active at once. While that can't ever happen on current versions of Mac OS X, it's not hard to imagine situations where it might be possible in the future. > > S+E > -- > Quinn "The Eskimo!" <http://www.apple.com/developer/> > Apple Developer Relations, Developer Technical Support, Core OS/Hardware > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/antoine.missout%40meta… > > This email sent to antoine.missout(a)metakine.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Quinn "The Eskimo!" 19 Aug '10

19 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 19 Aug 2010, at 21:09, Antoine Missout wrote: > What's the best way to do that ? Have the login agents tell you as they become active and inactive. Also, be prepared to have multiple agents active at once. While that can't ever happen on current versions of Mac OS X, it's not hard to imagine situations where it might be possible in the future. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Current active login session
by Antoine Missout 19 Aug '10

19 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, We have a daemon / gui agent pair. If multiple users are logged-in, there will be multiple agents, and we'd like to know which agent is currently active (or none if the computer is currently at the login window). What's the best way to do that ? Thanks! - Antoine _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0