Ensure that an autorelease pool is available in worker_pool_mac's WorkerPool::PostTask

Ensure that an autorelease pool is available in worker_pool_mac's
WorkerPool::PostTask.

BUG=38357, 20471
(but probably only peripherally)
TEST=no messages from __NSAutoreleaseNoPool() at launch

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=41871

[Scott Hess - ex-Googler, 2010-03-17 17:47:27]

LGTM.

I was thinking more like:
  scoped_nsobject<TaskOperation> op([[TaskOperation alloc] initWithTask:task]);
  [operation_queue addOperation:op];
[and get rid of +taskOperationWithTask: entirely], but I'm not entirely certain
this couldn't still need a pool for creating the singleton, so that might not be
complete.

I feel icky that tasks posted via WorkerPool will run w/in an autorelease pool,
but there may have been no autorelease pool when the task was posted.  It feels
like a subtle violation of some contract which will someday bite us when someone
comes along to refactor or something.  But I'm not sure what to do about it.

[Mark Mentovai, 2010-03-17 19:00:33]

shess@chromium.org wrote:
> I was thinking more like:
>  scoped_nsobject<TaskOperation> op([[TaskOperation alloc]
> initWithTask:task]);
>  [operation_queue addOperation:op];
> [and get rid of +taskOperationWithTask: entirely], but I'm not entirely
> certain
> this couldn't still need a pool for creating the singleton, so that might
> not be
> complete.

It's incomplete, not because of the singleton, but because NSOperation
(TaskOperation's superclass) autoreleases things in its own -init.
You can see this happening in bug 20471 comment 83.

> I feel icky that tasks posted via WorkerPool will run w/in an autorelease
> pool,
> but there may have been no autorelease pool when the task was posted.

You're giving a task to a completely different thread to run for you.
I don't think it's bad to have the autorelease pool in -main.  I don't
think that this is really relevant to the pool that I'm adding in
PostTask, either.

> It
> feels
> like a subtle violation of some contract which will someday bite us when
> someone
> comes along to refactor or something.  But I'm not sure what to do about it.

Something's always gotta bite...

Mark

[Scott Hess - ex-Googler, 2010-03-17 19:02:49]

anyhow, lgtm.

On Wed, Mar 17, 2010 at 12:00 PM, Mark Mentovai <mark@chromium.org> wrote:
> shess@chromium.org wrote:
>> I was thinking more like:
>>  scoped_nsobject<TaskOperation> op([[TaskOperation alloc]
>> initWithTask:task]);
>>  [operation_queue addOperation:op];
>> [and get rid of +taskOperationWithTask: entirely], but I'm not entirely
>> certain
>> this couldn't still need a pool for creating the singleton, so that might
>> not be
>> complete.
>
> It's incomplete, not because of the singleton, but because NSOperation
> (TaskOperation's superclass) autoreleases things in its own -init.
> You can see this happening in bug 20471 comment 83.
>
>> I feel icky that tasks posted via WorkerPool will run w/in an autorelease
>> pool,
>> but there may have been no autorelease pool when the task was posted.
>
> You're giving a task to a completely different thread to run for you.
> I don't think it's bad to have the autorelease pool in -main.  I don't
> think that this is really relevant to the pool that I'm adding in
> PostTask, either.
>
>> It
>> feels
>> like a subtle violation of some contract which will someday bite us when
>> someone
>> comes along to refactor or something.  But I'm not sure what to do about it.
>
> Something's always gotta bite...
>
> Mark
>