> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > 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/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159 > > I think it makes total sense for dispatch’s SPI for CF to simply return an > eventfd.
it’s exactly what we want for runloop tied queues. The mach port that is used for this on Darwin receives messages only to break out of the mach_msg() call, but the handler of the message is a void function: _dispatch_wakeup_runloop_thread(). The good news is that a mach_port is an uint32_t and eventfd would be an int, so as far as storage is concerned, everything is fine. I would have the _dispatch_get_main_queue_port_4CF / _dispatch_runloop_root_queue_get_port_4CF return an eventfd, and adapt the code that disposes of it. This is a IMO straightforward patch that should be written e.g. that way: #if HAVE_MACH // current OS X Code #elif HAVE_EVENTFD // linux port #else #error should not happen #endif And also have: DISPATCH_COCOA_COMPAT be set to one on linux (until it is, you don’t get the main queue and runloop tied queues). The one murky thing is that someone has to *consume* what’s in that eventfd, today, it’s implicit with mach because MiG will call dispatch’s _dispatch_wakeup_runloop_thread() for it (corresponding to the wakeup_runloop_thread routine in protocol.defs), but for linux, it’s probably best if CF knows that it’s an eventfd and it has to eventfd_read() from it to consume the event before it’s calling _dispatch_runloop_root_queue_perform_4CF(). The alternative is for _dispatch_runloop_root_queue_perform_4CF() to do that read in a non blocking way, but for the cases when several things have been queued on the runloop queue and have been coalesced in a single eventfd delivery, it’s a bit dumb to pay a syscall per dequeue. On Mach the coalescing happens because the port has a queue width of 1 and incoming messages are dropped when the port is full. -Pierre _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
