Re: NSTask not cleaning up it's threads
Re: NSTask not cleaning up it's threads
- Subject: Re: NSTask not cleaning up it's threads
- From: Ken Thomases <email@hidden>
- Date: Wed, 15 Oct 2008 03:54:30 -0500
On Oct 15, 2008, at 3:25 AM, C. Tearpak wrote:
Thanks for your insight, Ken.
You're welcome.
It's very possible that you are right, though I haven't tried your
suggestions, especially since you are mentioning the "wait" parameter.
Sorry, I didn't mean to be confusing. The -
performSelectorOnMainThread:withObject:waitUntilDone: method of
NSObject takes as its last argument a "wait" parameter. If it's YES
(or TRUE, etc.) then the caller is blocked until the main thread has
completed performing the selector. The request to perform a selector
on the main thread is carried out through the run loop mechanism. If
the main thread's run loop isn't running, then the caller of
performSelectorOnMainThread:withObject:waitUntilDone: won't ever
proceed and that thread will never get around to exiting.
I am normally a C# / .NET programmer by day, with other experience
in Java, so the RunLoop and Timer are still somewhat foreign
concepts to me, and when looking at threading, having control via
the NSThread is more familiar and less weird to me. Hopefully, that
will change, as I have seen APIs that require doing work via
RunLoops and I have run in to issues when an NSThread created by me
needs to interact with one.
I seem to have solved the problem. It seems like, after some
tinkering, adding a [task waitUntilExit]; before exiting the
runCommand method fixes the thread leak.
-waitUntilExit is documented to run the run loop. Doing things this
way, though, precludes running multiple tasks simultaneously.
I suppose it could be the fact that NSTask is "creating a separate
executable entity" per the NSTask documentation, and that, even
though it does not share memory space with my process, it would need
to communicate via the pipe that was configured for stdout. If the
objects created in that method were cleaned up and it could no
longer communicate via the pipe or whatever, it might just leak and
not know how or when to terminate itself.... That's what it seems
like, anyhow.
It is my impression that various asynchronous APIs in Cocoa use
background threads to carry out some operations synchronously and then
use something like -
performSelectorOnMainThread:withObject:waitUntilDone: to call delegate
methods or post notifications on the main thread. This may apply to
NSTask and the way it monitors the task it launches, and to
NSFileHandle in the way it performs I/O.
I don't think it has anything to do with the actual process management
going on within NSTask. That is, neither forking a child process nor
holding or reading a pipe necessarily requires the creation of a
thread nor keeping it alive. This is also not a memory management or
garbage collection issue.
However, this is just a guess and nobody should really count on such
internal implementation details. I know it's frustrating not to know
all the nitty-gritty details of what's going on. However, you just
have to accept that some of the framework classes will expect and
require that the run loop will be run.
Framework and API designers often hide implementation details. This
is for your protection and for their benefit. It protects you because
if you don't know the implementation details you can't build code
which relies on them. Then, your code doesn't break when they decide
to change the implementation. It benefits them because they have the
flexibility to change the implementation details to enable new
features for the framework.
If anyone has any insight as to the actual reason that this would be
happen and could shed light, I would definitely like to know what is
actually going on to gain a better understanding of the underlying
APIs and their interactions with executables and the environment.
Did you try my suggestion?
On Oct 14, 2008, at 10:46 PM, Ken Thomases wrote:
You can use Activity Monitor's Sample Process feature to get a
sense of what the extraneous threads are stuck waiting for.
Cheers,
Ken
_______________________________________________
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