site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 2010 Aug 20, at 11:16, Terry Lambert wrote:

On Aug 20, 2010, at 4:35 AM, Jerry Krinock wrote:

...

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.

The suggestion was made on the basis of incomplete information, which is why I gave a shotgun answer to cover all possible bases, given your observed behaviour. I wouldn't suggest throwing out NSThread and object encapsulation over this.

OK, I realized after reading this that NSThreads *are* pthreads. So I can create a thread with NSThread, and then when running in Mac OS 10.5, have the secondary thread identify itself using pthread_self(), and feed this back to the main thread.

I can't make forward looking statements about things like that. It works that way by design in 10.6.x. You could always ask for a documentation change to try and tie our hands in future versions.

Well, since I've always known you to be a very helpful and technical person, against the advice of my attorneys, I shall just trust you.

I tend to like to keep documented interface contracts to a minimum in man pages I work on, though, so as to not preclude doing something clever in the future; being with the IEEE, you can probably appreciate that, since POSIX says nothing about close(2) triggering cancellation of outstanding I/O operations vs. blocking until those operations complete. Writing code that depends on cancellation is therefore non-POSIX code which depends on implementation-defined behaviour.

I see. A little out of my league, but it seems that maybe this pickle is a result of the kqueue being inappropriately built upon a file handle.

I think the benefits of async initialization, no additional fd worries, and the mechanism being orthogonal to interfaces you are probably already using is enough of an argument to sell the signal approach.

OK, that's what I did and it works. When my kqueue is no longer needed, in Mac OS 10.5, I send it a pthread_kill() with SIGUSR1. My secondary thread handles SIGUSR1 with a no-op [1]. Then, in both 10.5 and 10.6, I close() the kqueue's file descriptor. In Apple's Threading Programming Guide > Terminating a Thread, killing a thread is "strongly discouraged" because "Memory allocated by the thread could potentially be leaked and any other resources currently in use by the thread might not be cleaned up properly, creating potential problems later." I don't see any other resources, and as far as memory, I've tried to fix that by only accessing Cocoa objects within inner autorelease pools, which are all released before re-camping on kevent(), and enclosing them, as well as my call to pthread_kill() over on the main thread, in @synchronized() blocks. The idea is that death shall not occur whilst any Cocoa objects are alive. Tested on both 10.5 and 10.6, and it all seems to work. Thank you for the help. Jerry [1] Otherwise the whole app gets killed – logical, but not precisely documented as far as I can see. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com