Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
- Subject: Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
- From: Jerry Krinock <email@hidden>
- Date: Fri, 20 Aug 2010 04:35:08 -0700
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden