Hi Dzianis, > On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > >>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev >>> <swift-corelibs-dev at swift.org> wrote: >>> >>> Hi, >>> >>>> On 8 dec. 2015, at 16:56, Pierre Habouzit <pierre at habouzit.net> wrote: >>>> >>>> FWIW, this is my personal, let’s call it enlightened, opinion, based on my >>>> knowledge of dispatch and my past extensive system programming experience >>>> with Linux before I joined Apple. >>>> >>>> I think that long term, the best way to maintain a Linux libdispatch port >>>> is to go away from the libkqueue that tries to emulate kqueue fully, where >>>> dispatch only needs a small subset of the surface of kqueue. Given how >>>> source.c is written today, this is not a very small undertaking, but >>>> eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well. >>> >>> That makes sense, could simplify the implementation (and keep thing >>> cleaner). Then the follow up question is of course how to split/manage >>> source.c (as Daniel pointed out there is the merging issue). >> we can decide when/if someone tries to tackle it. I humbly recognize that I >> have no great idea of how to do so. > > I have some experience in event multiplexing programming for linux. So it > looks like interesting project for me. There is some conceptual questions > which I think should be discussed: > > 1) Obviously, kqueue and epoll have a little different semantics. For > example: in linux timers, signals and socket can be presented as file > descriptor and processed uniformly. Is there any chance that community will > agree to develop separate API for linux?
For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of epoll: https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c <https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c> https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159 <https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159> I think it makes total sense for dispatch’s SPI for CF to simply return an eventfd. - Tony > 2) Does anyone have long term vision about how to inject platform specific > code into current implementation of dispatch_source? As far as I’ve read the > source it’s heavily bound with kqueue semantics and «#ifdef»-way seems to be > completely messy..( > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
