Re: CoreBase: necessary additions for WebKit

[Daniel Ferreira (theiostream)]

Stefan wrote:
> That seems reasonable. The only problem you'll probably run into is that, 
> from my understanding, NSRunLoop is built on top of CFRunLoop, and trying to 
> go the opposite direction might prove difficult. For example, it is not 
> immediately apparent to me how each iteration of the loop would be run. I 
> assume Apple simply adds observers, sources and timers directly to the 
> CFRunLoop inside the NSRunLoop.
> Additionally, I did not write the code in CFRunLoop, and I'm only vaguely 
> familiar with it. I think it was the author of Darling (for the life of me, I 
> cannot remember his name, now) so you probably want to direct your question 
> to him. CFRunLoop was one of the types that are over my head. I understand 
> how to use it, but not how to implement it.

David wrote:
> I suspect that this will probably not work, because the bridging expects the 
> two runloops to coexist.  Ideally, we’d have a libdispatch-based 
> implementation of both NSRunLoop and CFRunLoop and each would then be a 
> fairly thin wrapper around the underling dispatch queue.

I assume GS has some internal logic for NSRunLoop's implementation. I
haven't looked into it (and will probably only do in the course of the
next weeks), but would it seem reasonable to make CFRunLoop a wrapper
around this same implementation and use this to make NSRunLoop and
CFRunLoop share the same resources (i.e. same internal data structs
etc.)

This would require rewriting a good part of CFRunLoop, but it seems
more approachable than expecting Base's NSRunLoop to depend on
libdispatch.

Once again, I really haven't looked into it, so this may be totally
off. Just wondering whether there would be opposition even to this
basic idea.

> Note that the POSIX 2008 xlocale extensions (which are now widely supported 
> because the locale stuff in C++11 is ) were designed by Apple to implement 
> most of this functionality in libc, so they should be relatively easy to 
> implement now.  It would actually be very nice to reimplement a bunch of the 
> NSLocale stuff in terms of locale_t as well now.

It is exactly CFLocaleCopyPreferredLanguages() I'm talking about ;)
This is not a priority for me since I can adapt WebKit to assume en_US
or something like that as a default, but good to know a viable
implementation can be done. On the medium term, I may look into it.