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

[Bob I. <bo...@re...>]

On Apr 7, 2004, at 6:18 AM, Ronald Oussoren wrote:

>
> On 7-apr-04, at 11:21, Bob Ippolito wrote:
>
>>
>> On Apr 7, 2004, at 3:21 AM, Ronald Oussoren wrote:
>>
>>> 				
>>> On 6-apr-04, at 18:32, Bob Ippolito wrote:
>>>
>>>> Update of /cvsroot/pyobjc/pyobjc/Modules/objc
>>>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21862
>>>>
>>>> Modified Files:
>>>> 	objc_util.h objc_util.m
>>>> Log Message:
>>>> move the threadstate autoreleasepool key name into a macro so that
>>>> it can be checked when calling _into_ ObjC at some point so that 
>>>> python
>>>> threads can create an NSAutoreleasePool and call +[NSThread 
>>>> currentThread]
>>>> (not necessarily in that order).
>>>
>>> I'm probably pretty dense (no coffee yet), but why is 
>>> PyObjCGILState_Ensure necessary at all?
>>>
>>> This seems to create an arbitrary NSAutoreleasePool the first time 
>>> someone calls into python from ObjC, and that might not play nicely 
>>> with existing pool (e.g. what if the calling code already created a 
>>> pool and later releases that to clean up memory, our pool might 
>>> contain objects that should be cleaned up).
>>>
>>> It should be possible to create a new autorelease pool inside a 
>>> thread before doing anything else with Cocoa.
>>
>> That is exactly what it is doing.  If Python has never seen this 
>> thread before, and we are in an objc method stub, then assume that we 
>> need to create an NSAutoreleasePool.  It only happens for threads 
>> that have no threadstate yet.
>
> But why create an autorelease pool? The thread may be a perfectly 
> valid thread that already has an autorelease pool, such as internal 
> background threads used by Cocoa.

Because creating one is harmless, and if you don't create one you leak 
memory.

-bob