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" <lu...@dolezel.info> 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
