libdispatch ne nécessite pas d'appeler dispatch_main()
, il intègre à la runloop du thread principal par l'envoi file d'attente principale, voir dispatch_get_main_queue(3)
et la section COMPATIBILITY
celle-ci. Les exécutables qui n'appellent pas dispatch_main()
et qui veulent utiliser la file d'attente principale doivent exécuter la boucle d'exécution principale dans l'un des modes communs pour que les blocs de la file d'attente principale d'acheminement soient traités; soit indirectement via des méthodes de structure standard (par exemple, NSApplicationMain()
), soit directement via les API CFRunLoop ou NSRunLoop. Veuillez ne pas essayer d'utiliser le symbole _dispatch_main_queue_callback_4CF
, il s'agit d'un détail d'implémentation interne à la bibliothèque qui est susceptible de changer dans le futur et tout code qui en dépendra se cassera sans avertissement.
L'intégration de libdispatch avec CFRunLoops non-thread personnalisé peut être réalisée de plusieurs façons, par exemple via l'API CFRunLoopPerformBlock()
ou des sources de routage personnalisées.
Mise à jour: sur Linux, vous devrez modifier les sources de libdispatch, il n'y a pas de soutien existant pour interopérer avec runloops sur mesure AFAIK.
La façon la plus simple d'intégrer la file d'attente principale avec un runloop existant sur Linux va probablement bien être d'appeler le (de préférence renommé) _dispatch_main_queue_callback_4CF()
fonction à chaque fois dans la boucle d'événements, et remplacer _dispatch_queue_wakeup_main()
par toute méthode appropriée pour réveillez votre runloop (par exemple, écrivez sur un tuyau que le runloop attend).
J'essaie d'utiliser libdispatch sur un système Linux (ergo la restriction NSRunLoop/CFRunLoop). Je suppose que j'aurais dû être plus clair à ce sujet dans mon message original. J'utilise les sources Debian de libdispatch pour le même (libkern/libpthread_workqueue/libkqueue). – Buzzy
C'est exactement correct. Je suis juste arrivé à une solution similaire moi-même. Merci beaucoup! – Buzzy