[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: corebase runloop integration
From: |
Luboš Doležel |
Subject: |
Re: corebase runloop integration |
Date: |
Tue, 04 Feb 2014 14:56:24 +0100 |
User-agent: |
Roundcube Webmail/0.5 |
On Tue, 4 Feb 2014 10:05:59 +0000, Niels Grewe wrote:
The ability to invoke blocks doesn’t really commit you to using clang
(-base has support code to invoke blocks when compiled with GCC) you
only need it when you want to create blocks (does CFRunLoop need to
do
that? I think it might not…). So the question is rather whether we
could rely on a compatible libBlocksRuntime being reasonably
widespread (libdispatch usually isn’t the issue, but you need the
version libBlocksRuntime that exports is symbols weakly so that
libobjc2 can override them). In other words: I don’t think
backwards-compatibility is as important for corebase as it is for
-base.
Creating blocks in CoreBase can be avoided, but as usual, it makes
things easier. I'm just upset by the fact that supporting a compiler,
which does not and probably will not stay current with the technologies
used on OS X, is stopping us from becoming more efficient.
Whenever I see someone using libBlocksRuntime, I tell him to simply use
libobjc2. But then again, it is up to whoever compiles to code (end
user, distro maintainer) to make the right choices for the right
packages.
I have one comment about the
‘weakly-load-NSCFRunLoop-if-corebase-is-also-linked’ thing: I think
it’s a good idea in general, but how would we handle cases where you
start up without corebase, and during runtime you load a bundle that
is linked against it? That might be a bit tricky to get right…
Good point. I suppose that this case will not work, until one day APIs
are layered correctly and NSRunLoop always uses CFRunLoop.
=============
Now to the technical topics. I imagine the following:
All CFRunLoops:
* Have a pipe descriptor pair and the run loop polls the reading end.
This is so that the run loop can be woken up to do any work
(CFRunLoopWakeUp(); check for timers fired, sources fired etc.).
(remember: CF main loop doesn't poll any application supplied fds, run
loop sources do this on their own)
Main CFRunLoop additionally:
* Uses dispatch_get_main_queue_eventfd_np/dispatch_main_queue_drain_np
to get and use an extra pollable fd. (dispatch_main() cannot be used,
otherwise e.g. CFRunLoopStop wouldn't be implementable.)
Timers:
* Timers are implemented as libdispatch sources handled in a separate
queue.
* Timer handlers only mark the timer as fired and attempt to wake up
the associated CFRunLoop.
Other run loop sources:
* Socket-based run loop sources use libdispatch's global queue (or
possibly a private queue?) for its own polling.
What do you think?
--
Luboš Doležel
- corebase runloop integration, Luboš Doležel, 2014/02/03
- corebase runloop integration, Ivan Vučica, 2014/02/03
- Re: corebase runloop integration, Stefan Bidi, 2014/02/03
- Re: corebase runloop integration, Luboš Doležel, 2014/02/03
- Re: corebase runloop integration, Luboš Doležel, 2014/02/03
- Re: corebase runloop integration, David Chisnall, 2014/02/04
- Re: corebase runloop integration, Luboš Doležel, 2014/02/04
- Re: corebase runloop integration, Niels Grewe, 2014/02/04
- Re: corebase runloop integration,
Luboš Doležel <=
- Re: corebase runloop integration, Owen Shepherd, 2014/02/04
- Re: corebase runloop integration, Luboš Doležel, 2014/02/04