Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

> Last time I was digging through the OBJ-C documentation about
> AutoReleasePools I recall seeing something that indicated that the runtime
> generally creates one before it invokes a thread.  That said, I do have the
> following code in java_lang_Thread.m for a reason:
>
> - (void) threadCallback: (id) arg
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [runnable run__];
>  [self release];
> [pool release];
> }
> Because apparently, at least in certain cases, you are responsible for
> creating the pool...
>
> The above pattern, plus the assumption that the runtime creates pools
> as necessary should prevent any problems.
>
> Let me know if you have any issues...
>
>
> -- Joshua Melcon
>
>
> 2010/3/25 Panayotis Katsaloulis <pan...@pa...>
>
>
>> On 25 Μαρ 2010, at 1:36 μ.μ., Arno Puder wrote:
>>
>> >
>> > Guys,
>> >
>> > I have just committed a patch submitted by Joshua Melcon. His patch
>> > removes the dependency on NSAutoreleasePool during code generation.
>>
>> I have a question here:
>> What if a selector is called from a separated thread?
>> AFAIK, when a new thread is fired, there is no autorelease pool for that.
>>
>> In the new code, I can see inside java_lang_Thread.m that in selector
>> threadCallback, there is a new autorelease pool.
>> I haven't deeply had a look at the code, but I am wondering if this will
>> cover this problem.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
>