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_be
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 bl
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
On 1 Mar 2013, at 18:15, Jean-Charles BERTIN wrote:
> Hmmm sorry but its clearly none of these solutions that will fix the
> problem: if context watchers is empty the run loop will never execute
> -[GSRunLoopCtxt pollUntil:within:]!
>
> So I suggest an another patch to fix this.
Adding support
Hmmm sorry but its clearly none of these solutions that will fix the
problem: if context watchers is empty the run loop will never execute
-[GSRunLoopCtxt pollUntil:within:]!
So I suggest an another patch to fix this.
Sorry for the inconvenience.
Regards
On Fri, 2013-03-01 at 17:39 +0100, Jean-C
Ok, I didn't see this one: by adding systematically the dispatch watcher
in GSRunLoopCtxt for the main thread, I broke the -[NSRunLoop run] and
-[NSRunLoop runUntilDate:] methods. Since there is always at least one
watcher, the methods never return.
I wonder how I can correct this:
1/ add an ivar
---
Source/GSRunLoopWatcher.h | 11 +++
Source/GSRunLoopWatcher.m | 163 ++--
Source/unix/GSRunLoopCtxt.m | 13
3 files changed, 182 insertions(+), 5 deletions(-)
diff --git a/Source/GSRunLoopWatcher.h b/Source/GSRunLoopWatcher.h
index 0812692..1
