{"action":"created","issue":{"url":"https://api.github.com/repos/etcimon/libasync/issues/66","repository_url":"https://api.github.com/repos/etcimon/libasync","labels_url":"https://api.github.com/repos/etcimon/libasync/issues/66/labels{/name}","comments_url":"https://api.github.com/repos/etcimon/libasync/issues/66/comments","events_url":"https://api.github.com/repos/etcimon/libasync/issues/66/events","html_url":"https://github.com/etcimon/libasync/issues/66","id":159388057,"number":66,"title":"[Enhancement] Proactor pattern for IO","user":{"login":"Calrama","id":497073,"avatar_url":"https://avatars.githubusercontent.com/u/497073?v=3","gravatar_id":"","url":"https://api.github.com/users/Calrama","html_url":"https://github.com/Calrama","followers_url":"https://api.github.com/users/Calrama/followers","following_url":"https://api.github.com/users/Calrama/following{/other_user}","gists_url":"https://api.github.com/users/Calrama/gists{/gist_id}","starred_url":"https://api.github.com/users/Calrama/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Calrama/subscriptions","organizations_url":"https://api.github.com/users/Calrama/orgs","repos_url":"https://api.github.com/users/Calrama/repos","events_url":"https://api.github.com/users/Calrama/events{/privacy}","received_events_url":"https://api.github.com/users/Calrama/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":87,"created_at":"2016-06-09T11:42:28Z","updated_at":"2016-07-28T21:06:26Z","closed_at":null,"body":"AFAICT libasync currently uses the UNIX-style reactor pattern (i.e. synchronous IO with asynchronous event notification) both for all backing IO operations, as well as its interface to the user.\r\nThere are two issues with this for me:\r\n1. On Windows, using the reactor pattern makes little sense to me, as [Windows is natively procator](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx) and [its performance is optimized for it](https://support.microsoft.com/en-us/kb/181611). So on Windows one should use overlapped IO (i.e. proactor) for backing IO operations, which leads me to\r\n2. While emulating the proactor pattern using reactor [is comparatively simple and cheap](http://www.artima.com/articles/io_design_patternsP.html), the other way around would - AFAIK - inevitably result in copy overhead (from the buffer used for dispatching to the OS proactor pattern to the frontend user in the reactor pattern).\r\n\r\nThe only sensible solution to me seems to be using the proactor pattern as the frontend interface [(e.g. as libuv does)](http://libuv.org/) and dispatching to whatever the OS provides for its actual IO operations:\r\n- proactor for Windows\r\n- reactor for UNIX by default\r\n- proactor for those POSIX systems, that implement [POSIX AIO](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html) correctly, maybe for them also as the default instead, if they beat their own reactor pattern with it in terms  of performance (needs benchmarking)\r\n\r\nNow, since this would most probably require a severe rewrite of several key components of libasync *and* any users of libasync (at the same time it might make sense to make the new stuff `@nogc` in line with what I perceived to be the general consensus at DConf2016), I wanted to know if this is something you would even consider.\r\nIf not (and I can think of several reasons why it might not make sense at this point in time to change libasync's core in this way), I can write and test this in a (separate) small project on my own directed at only IO (no timers, etc.). In some ways, it might even make more sense to do the latter anyway, as it would allow me more freedom from libasync's current infrastructure and speed up the initial development, but if you intended to take libasync in this direction anyway, me implementing this separately would equal an unconscionable duplication of effort (one Dlang simply cannot afford with its current community size IMHO)."},"comment":{"url":"https://api.github.com/repos/etcimon/libasync/issues/comments/236025190","html_url":"https://github.com/etcimon/libasync/issues/66#issuecomment-236025190","issue_url":"https://api.github.com/repos/etcimon/libasync/issues/66","id":236025190,"user":{"login":"etcimon","id":4785754,"avatar_url":"https://avatars.githubusercontent.com/u/4785754?v=3","gravatar_id":"","url":"https://api.github.com/users/etcimon","html_url":"https://github.com/etcimon","followers_url":"https://api.github.com/users/etcimon/followers","following_url":"https://api.github.com/users/etcimon/following{/other_user}","gists_url":"https://api.github.com/users/etcimon/gists{/gist_id}","starred_url":"https://api.github.com/users/etcimon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/etcimon/subscriptions","organizations_url":"https://api.github.com/users/etcimon/orgs","repos_url":"https://api.github.com/users/etcimon/repos","events_url":"https://api.github.com/users/etcimon/events{/privacy}","received_events_url":"https://api.github.com/users/etcimon/received_events","type":"User","site_admin":false},"created_at":"2016-07-28T21:06:26Z","updated_at":"2016-07-28T21:06:26Z","body":"I think this issue will take a while to figure out, it could also be a compiler issue. I would reduce the complexity of the code, ie. make it as simple as possible for the compiler. Having no extern(C) members is an example of that."}}
{"actor":{"display_login":"etcimon"}}