Подтвердить что ты не робот

Mac OS X: можно ли внедрить не основной поток, чтобы стать "основной нитью" процесса?

У меня проблема с GUI/Threading, связанная с Mac OS X (10.6.7). Я использую фреймворк wxWidgets (версия 2.9.1), и он зависит от Cocoa в моем случае. Дизайн приложения выглядит следующим образом:

  • thread # 1 (a.k.a. "Основная тема" ): вводит main(), анализирует коммутаторы и при необходимости запускает другой поток (используя примитивы POSIX).
  • thread # 2 (a.k.a. "поток GUI" ): использует wxEntry для инициализации wxWidgets и отображения графического интерфейса.

Как и большинство других графических интерфейсов GUI, Cocoa не является потокобезопасным, поэтому мы обязательно выполняем все вызовы GUI из потока # 2, передавая сообщения, если это необходимо. Тем не менее, в этом конкретном случае утверждение возникает изнутри Cocoa внутренних элементов во время инициализации (точнее, из NSUndoManager), говорящего, по существу, "небезопасно использовать меня вне основного потока". Несмотря на то, что поток # 2 является основным потоком, поскольку речь идет о связанных с GUI.

Ну, NSUndoManager должен иметь способ узнать, как он убегает от основного потока (возможно, используя NSThread:: isMainThread()). Поэтому мой вопрос: можно ли обмануть NSUndoManager (и Cocoa в целом) об этом? И еще лучше, чтобы объявить поток №2 "главной темой", при этом нить # 1 станет вторичной? В принципе, мне нужен API-вызов, например "сделать вызывающий поток" основным ". Недокументированное волшебство и Objective С++ в порядке, если оно работает и с OS X 10.5.

P.P. код, как и сейчас, работает безупречно под Windows/Linux/MacOSX + Carbon. Кроме того, перепроектирование его для изменения структуры потока было бы огромной болью.

4b9b3361

Ответ 1

ОК, поэтому в соответствии с вашим комментарием: вы в основном не избежите рефакторинга своего кода. Большинство GUI-систем используют основной поток и обрабатывают циклы событий для себя. Но если вы скажете, что графический интерфейс не является обязательным, возможно, лучше разделить ваше приложение на двух рабочих и графический интерфейс. GUI мог бы взаимодействовать с работником различными способами, в зависимости от платформ/конкретных потребностей.