>> 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? 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
