pthread_kill в GCD-управляемый поток
Я пытаюсь отправить сигнал определенной теме с pthread_kill, я использую pthread_from_mach_thread_np() чтобы получить ручку, а затем использовать pthread_kill отправить сигнал.
Это хорошо сработало в моем другом тестировании, но теперь я вижу, что при попытке сообщить о потоке, внутренне созданном GCD, я получаю код возврата 45 от pthread_kill,
GCD API, который породил этот поток:
dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{ ... });
По какой причине это происходит?
-
Чтобы добавить дополнительную информацию, я не пытаюсь уничтожить потоки. pthread_kill() является стандартным API POSIX для отправки сигналов потокам. Если установлен обработчик сигнала, контекст потока переключается с помощью батута на обработчик.
Хотя то, что я пытаюсь достичь с помощью моего обработчика сигнала, может быть достигнуто лучшими способами, здесь это не рассматривается. Даже если по чисто академическим причинам я бы хотел понять, что здесь происходит внутри страны.
2 ответа
pthread_kill() API специально запрещен для потоков рабочих очередей (рабочих потоков, лежащих в основе GCD) и возвращает ENOTSUP для таких тем.
Это в первую очередь предназначено для предотвращения выполнения произвольных обработчиков сигналов в контексте кода, который может этого не ожидать (поскольку эти потоки являются общим ресурсом, используемым многими независимыми подсистемами в процессе), а также для абстрагирования этого контекста выполнения таким образом, чтобы у системы есть свобода изменить это в будущем.
Вы можете увидеть детали того, как это достигается в реализации.
Это очень плохая идея. У вас нет пула потоков GCD, и вы абсолютно не должны уничтожать его потоки из-под него.
Ответ на ваш вопрос: НЕ ДЕЛАЙТЕ ЭТОГО ПОД НИКАКИМИ ОБСТОЯТЕЛЬСТВАМИ.