<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Dzianis,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev <swift-corelibs-dev at <a href="http://swift.org" class="">swift.org</a>> wrote: <br class=""><br class="">Hi, <br class=""><br class=""><blockquote type="cite" class="">On 8 dec. 2015, at 16:56, Pierre Habouzit <pierre at <a href="http://habouzit.net" class="">habouzit.net</a>> wrote: <br class=""><br class="">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. <br class=""><br class="">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. <br class=""></blockquote><br class="">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). <br class=""></blockquote>we can decide when/if someone tries to tackle it. I humbly recognize that I have no great idea of how to do so.<br class=""></blockquote><br class="">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:<br class=""><br class="">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?<br class=""></div></div></blockquote><div><br class=""></div><div>For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of epoll: </div><div><br class=""></div><div><a href="https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c" class="">https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c</a></div><div><br class=""></div><div><a href="https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159" class="">https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159</a></div><div><br class=""></div><div>I think it makes total sense for dispatch’s SPI for CF to simply return an eventfd.</div><div><br class=""></div><div>- Tony</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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..(<br class="">_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>