[swift-corelibs-dev] libdispatch epoll port

[Dzianis Fedarenka]

>> 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..(