Используя ARC, неужели у него нет пула авторесурсов для каждого потока?

Я читал это:

Если вы когда-либо создавали дополнительный поток в своем приложении, вам необходимо предоставить его собственный пул автозаполнения. Пулы Autorelease и объекты, которые они содержат, обсуждаются далее в

в кулинарной книге разработчика iOS 5.

Я собираюсь с ARC. Я создаю много фоновых потоков, и кажется, что я в порядке. Ни один из моих фоновых потоков не работает. Будут ли выпущены все эти объекты, скажем, пул авторефератов основной нити? Или что?

Это то, что я делаю, чтобы вызвать фоновый поток:

+(void)doBackground:(void (^)())block
{
    //DISPATCH_QUEUE_PRIORITY_HIGH
    //dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0), ^{
    dispatch_async(dispatch_get_global_queue(-2,0), ^{
        block();
    });
}

Должен ли я изменить это на

+(void)doBackground:(void (^)())block
{
    //DISPATCH_QUEUE_PRIORITY_HIGH
    //dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0), ^{
    dispatch_async(dispatch_get_global_queue(-2,0), ^{
        @autoreleasepool{
        block();
        }
    });
}

Ответ 1

Считайте это, как минимум, ошибкой программиста, если вы не создаете пул автозапуска для вашего нового потока. Независимо от того, является ли эта фатальная для вашей программы ваша реализация программы. Классической проблемой являются просочившиеся объекты и, следовательно, объекты dealloc, которые никогда не выполняются (могут быть фатальными).

Современный способ создания пула автозапуска при ARC:

void MONThreadsEntry() { // << entry is e.g. a function or method
  @autoreleasepool {
    ...do your work here...
  }
}

Более подробно, пулы авторекламы ведут себя как поточно-локальные стеки - вы можете нажать и поп, но всегда должен быть один на месте, прежде чем что-либо из этого потока будет автореализовано. Сообщения об автоопределении не передаются из одного потока в другой.

Вы можете не видеть проблем (например, в консоли или утечек), если в вашей идее "создания потока" используется асинхронный механизм более высокого уровня, например, с использованием NSOperationQueue или если базовая реализация создает вторичный поток и его собственный автореферат.

В любом случае, вместо того, чтобы угадывать, когда создавать пулы автозапуска, просто узнайте, где вы должны их создавать, и когда вы должны их создать. Все это четко определено - нет необходимости в догадках, и нет необходимости бояться создавать их.

Аналогичным образом вам никогда не понадобится создать пул автозапуска для вашего потока, если вы используете абстракции более низкого уровня и никогда не создаете объекты автоповторения в этом потоке. Например, pthreads и чистые C-реализации не будут нуждаться в пулах автозапуска (если только какой-либо API, который вы используете, не предполагает, что они существуют).

Даже основной поток в приложении Cocoa нуждается в пуле автозапуска - он обычно не является тем, что вы пишете, потому что он существует в шаблонах проекта.

Обновление - очереди отправки

В ответ на обновленный вопрос: да, вы должны создавать пулы автозаполнения для своих программ, которые выполняются под очередями отправки - обратите внимание, что с очередью отправки вы не создаете темы, так что это совсем другой вопрос от оригинала вопрос. Причина. Хотя очереди отправки управляют пулами автозавершения, нет гарантии в отношении времени/пункта, которые они опустели. То есть ваши объекты будут выпущены (в какой-то момент), но вы должны также создать пулы автозапуска в этом контексте, потому что реализация может (теоретически) истощать пул каждые 10 000 блоков, которые он запускает, или примерно каждый день. Таким образом, в этом контексте он действительно только смертелен в сценариях, например, когда вы в конечном итоге потребляете слишком много памяти или когда ваши программы ожидают, что его объекты будут уничтожены определенным образом - например, вы можете загружать или обрабатывать изображения в фон и поток, потребляющий тонну памяти, если жизнь этих изображений неожиданно расширяется из-за пулов автоопределения. Другим примером являются общие ресурсы или глобальные объекты, где вы можете отвечать на уведомления или вводить условия гонки, потому что ваши "локальные локальные объекты" могут жить намного дольше, чем вы ожидаете. Также помните, что реализация/частота могут свободно меняться по мере ее соответствия разработчикам.

Ответ 1

Ответ 2