[swift-corelibs-dev] libdispatch epoll port

[Dzianis Fedarenka via swift-corelibs-dev]

>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev 
>>  wrote: 
>>  
>> Hi, 
>>  
>>> On 8 dec. 2015, at 16:56, Pierre Habouzit  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

Re: [swift-corelibs-dev] libdispatch epoll port

[Tony Parker via swift-corelibs-dev]

Hi Dzianis,

> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev 
>  wrote:
> 
>>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev 
>>>  wrote: 
>>> 
>>> Hi, 
>>> 
 On 8 dec. 2015, at 16:56, Pierre Habouzit  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.

- 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