Re: [PATCH 18/21] Added support for libdispatch main queue in the main run loop.

[Jean-Charles BERTIN]

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 
> address@hidden 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