Re: APE's and thread termination
Re: APE's and thread termination
- Subject: Re: APE's and thread termination
- From: "Martin Redington" <email@hidden>
- Date: Fri, 17 Nov 2006 01:39:48 +0000
Hi Peter,
I just checked for any APE or other non-standard stuff (input
managers, etc). but I don't seem to have any.
I'm definitely not leaking *threads* in my production code, although
the original Apple Sample code doesn't seem to terminate them properly
(a define in the SimpleThreads code I referred to uses a more "modern"
approach, based on other sample code, and does definitely terminate
the worker threads).
However, I do notice that I seem to have an ever increasing number of
ports associated with my process.
Based on stack traces, and debugger runs, Cristian Draghici suggested
that therer could be a problem with a port allocation call, and
someone else indicated that they had seen problems with DO leaking
ports, that eventually impacted the wider system ...
On 11/16/06, Peter Sichel <email@hidden> wrote:
On 11/16/06, Martin Redington wrote:
>However, it only seems to manifest itself after a large number of
>threads have been created, and is very hard to reproduce normally
>(although we have test cases that will reliably get it) - if yours is
>like this, its possible that you just haven't hit it on 10.4 yet.
>
>Interestingly I can get the crash with (a variant of) the
>SimpleThreads example, whose original author was ... Quinn "The
>Eskimo!"
I just tracked down an interesting APE related bug. Following Apple's
sample code (TrivialThreads and SimpleThreads), I use Distributed
Objects (DO) to coordinate multiple pre-emptively scheduled secondary
threads to do asynchronous networking. Following Apple's example, the
controller invalidates the NSConnection when it wants the server to terminate.
// we invalidate our send port, which will invalidate the connection in the
// threaded object, causing its runloop to abort and the thread to exit.
[[connect receivePort] invalidate];
In theory, this removes the connection as an input source to the
runloop, and since that was the only input source configured, the
runloop aborts.
But if the user has installed an APE, there could be another input
source for the runloop your program doesn't know about, so the thread
never dies. A customer reported the app was eating threads (which it
was on his system, but not on mine). The solution was to re-write the
runloop code to include an external test. I noticed Apple updated the
documentation for NSRunLoop to clarify that removing the last input
source is not guaranteed to exit the runloop, but the sample code is
still wrong. If the user has an APE, threads will leak or even conflict
causing unpredictable results.
You may want to search ~/Library for files with "APE" in their filename.
Kind Regards,
- Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden