I think, being as GNUStep is not limited by the limitations of OS X - why is an extension with while descriptor sources not under consideration
On 4 Feb 2014 13:56, "Luboš Doležel" <
address@hidden> wrote:
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
_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev