Let me explain this. libdispatch on MacOS exports several symbols to handle integration with CoreFoundation:
1/ _dispatch_begin_NSAutoReleasePool/_dispatch_end_NSAutoReleasePool which are used by CF to handle ARP creation/destruction for its worker threads. 2/ dispatch_begin_thread_4GC/dispatch_begin_thread_4GC which are used to register worker threads with garbage Collection. 3/ dispatch_no_worker_threads_4GC which I ignore the meaning. 4/ _dispatch_get_main_queue_port_4CF/_dispatch_main_queue_callback_4CF to handle the libdispatch main queue inside the main run loop. - 1,2 and 3 are pointer to functions which are initialized inside libdispatch with no-op functions. CF replace them with its own implementation. I added these missing implementations in the patches 14, 15 and 16. - 4 are used inside CFRunLoop (cf <http://www.opensource.apple.com/source/CF/>) to pump the jobs of the main queue. The main problem here is that if you don't pump the jobs in the main thread's run loop, they are executed inside the default overcommit thread which is just plain wrong if your code expect that run loop inputs/performers are run sequentially with main queue jobs. So I write a GSRunLoopWatcher singleton to handle the main queue pump inside the main thread. This works great because I am able to mimic exactly the MacOS behavior, that is: * Avoid reentrancy in the main queue's pump * Prioritize the main queue against the inputs/performers I renamed the _dispatch_get_main_queue_port_4CF/_dispatch_main_queue_callback_4CF symbols to _dispatch_get_main_queue_port_4GS/_dispatch_main_queue_callback_4GS because the implementation for GNUstep is quite different than MacOS. I use a pipe to send 'events' to GNUstep instead of a mach port since it is far more portable. The related patches are 17 to 20. I am terribly sorry for the patches that applies to precedent patches but actually I use git format-patch to handle them and that's the way it works. I can rewrite those patches if you want to be more friendly with SVN. Regards On Mon, 2013-03-04 at 10:58 +0000, Richard Frith-Macdonald wrote: > On 4 Mar 2013, at 10:43, Niels Grewe wrote: > > > On 04.03.2013 10:00, Richard Frith-Macdonald wrote: > > > >> the first, smaller patch, to change configure.ac and the cofig.h.in and > >> base.make.in files to detect the presence/usability of libdispatch (would > >> we only consider it usable if we had block support?), > > > > We already have a working check for libdispatch, which automatically > > enables it for the concurrent collection enumeration/sorting/filtering > > stuff if it is usable together with libobjc2 (whether it is depends on > > whether you have the recent release of libBlocksRuntime). We don't even > > need blocks support for that, because we have a macro that can call a > > block even if the compiler doesn't support calling it directly. The > > changes Jean did to the configure scirpt seem to be to detect presence > > of his personal version of libdispatch, which introduces some callbacks > > that are not immediately obivous to me (with a _4GS suffix, so I expect > > they are required exclusively for GNUstep). I would prefer these > > changes to be explained and suggested for inclusion into the upstream > > libdispatch before we integrate those patches. I don't think we want to > > maintain what effectively constitutes a fork of libdisaptch that is only > > useful to us. > > That sounds reasonable. While looking around on the net I found a comment > about integrating using a _4CF function (which I guess is for > CoreFoundation), along with someone else saying not to use that function as > it's not part of the public API. So it seems plausible that there's room for > adding some public function to libdispatch which will allow event loop > integration into both GNUstep and CoreFoundation. > _______________________________________________ Gnustep-dev mailing list > Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Jean-Charles BERTIN Axinoe - Software Engineer Tel.: (+33) (0)1.80.82.59.23 Fax : (+33) (0)1.80.82.59.29 Skype: jcbertin Web: <http://www.axinoe.com/> Certificate Authority: <https://ca.axinoe.com/axinoe-root.crt>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev