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 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.


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