<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=""><div class="">libev model isn’t compatible with dispatch model, and retrofiting one on top of the other will put you in a world of hurt, and would diverge from the OS X port greatly, which we’d like to avoid.</div><div class=""><br class=""></div><div class="">I originally thought you were replying to the thread about having the Runloop queues code in dispatch ported (for some reason your reply wasn’t attached to a mail thread for me and I got confused), and that one needs a raw interface with epoll to interact with CFRunlopp and that’s what I “replied” to.</div><div class=""><br class=""></div><div class=""><div class="">I don’t think that moving away from likqueue is a good idea yet. Technically, dispatch is really interleaved with kqueue code, and libkqueue overhead is smaller than I originally thought, so I’ve kind of revisited that argument.</div><div class=""><br class=""></div></div><div class="">The one thing that will be painful for the port to an extent, is that kevents are now uniquified in kernel based on the ident + udata, said another way, if you watch the same file descriptor twice with two different udata’s, then it’s two different kevents in kernel. That is *NOT* the case with epoll, where uniquing is only based on the file-descriptor: if you EPOLL_CTL_ADD two different “udata” for the same fd, you get EEXIST, which means that you need to do multiplexing in userland (which dispatch used to do before kevent started taking udata into account).</div><div class=""><br class=""></div><div class="">That has impacts on the userland parallelism as all source registering and deregistering have to be serialized wrt each other. This is the hard part, not abstracting epoll.</div><div class=""><br class=""></div><div class="">
-Pierre
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 1:44 PM, Thomas Greany 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 dir="ltr" class="">What about libev? <a href="http://software.schmorp.de/pkg/libev.html" class="">http://software.schmorp.de/pkg/libev.html</a></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 17, 2015 at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev <span dir="ltr" class=""><<a href="mailto:swift-corelibs-dev@swift.org" target="_blank" class="">swift-corelibs-dev@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev <swift-corelibs-dev at <a href="http://swift.org/" rel="noreferrer" target="_blank" class="">swift.org</a>> wrote:<br class="">
>><br class="">
>> Hi,<br class="">
>><br class="">
>>> On 8 dec. 2015, at 16:56, Pierre Habouzit <pierre at <a href="http://habouzit.net/" rel="noreferrer" target="_blank" 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="">
>><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="">
> 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="">
<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="">
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="">
<a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br class="">
</blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ST9LHNQ2kYRKURQJ7G-2FmGJ7cPtWGB-2BbbnqmgrSbiwvj3HIjdTosqITH2uWAy9s029H1NKywjX7GKZixq1RC3BLmC8-2FJIkilQr8LE1S8LQ60INHaE8OxFNtzudqdYobOpxakPGuC7v85rpqwc5XCRlvc39ZJmHqQpXOfnEaMOcJmAhtbMWQiPD2Lw8-2BRGfM3WxLIzkDVcmQqVq0xcGsRjFd-2BjX0p0s71X7R6UrIHrU98-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" 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></blockquote></div><br class=""></body></html>