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

[Richard Frith-Macdonald]

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.

signature.asc
Description: Message signed with OpenPGP using GPGMail