Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc objc_util.h,1.24,1.25 objc_util.m,1.48,1.49

[Ronald O. <ous...@ci...>]

On 7-apr-04, at 19:30, Bob Ippolito wrote:

>
> On Apr 7, 2004, at 1:17 PM, Ronald Oussoren wrote:
>
>>
>> On 7-apr-04, at 19:11, Bob Ippolito wrote:
>>>
>>> Because creating one is harmless, and if you don't create one you 
>>> leak memory.
>>
>> Creating one is not harmless if you never release it, you still leak 
>> memory without any message about this.
>>
>> We currently leak 1 NSInvocation while creating the NSAutoreleasePool 
>> in a new thread, and this is logged. Because it is logged I get 
>> nagged anytime I run the unittests, which makes it more likely that 
>> this problem will be fixed.
>
> The NSAutoreleasePool goes away whenever the threadstate dict does, 
> and that's up to Python to decide.  My best guess is that it goes away 
> as soon as you call PyGILState_Release, but I have not yet looked at 
> the implementation.

It goes away when the gilstate_counter is 0, which is when you call 
PyGILState_Release.

I'm not sure what happens when you call into ObjC from a thread that 
already has a python threadstate (e.g. a thread created using 
thread/threading).  From a fairly light reading of the source I assume 
that the pool won't be released until the thread dies.

>
> +[NSThread detachNewThreadSelector:toTarget:withObject:] leaks memory 
> without these autorelease pools because "primitive" types such as 
> NSString will cause an autorelease to happen while creating a python 
> shadow type (like pyobjc_unicode) before any code gets executed in the 
> new thread.

Hmm, I hadn't though about those API's.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173