Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async: getSystemHandle() to retrieve associated IOCP handle from dispatcher. #4941

Closed
wants to merge 1 commit into from

Conversation

cheatfate
Copy link
Member

Add procedure getSystemHandle() for Windows part of asyncdispatch.nim.
Such procedure allow to access IOCP port handle and create more flexible async solutions, without dirty hacks.

@dom96
Copy link
Contributor

dom96 commented Oct 23, 2016

Could we also offer the same thing for epoll/kqueue?

@cheatfate
Copy link
Member Author

cheatfate commented Oct 23, 2016

@dom96, there is a problem with selectors.
If we return selectors handle, then selectors must implement all possible variants of usage, if we return epoll/kqueue descriptor, then selectors can have problems with unsupported flags, like EVFILT_TIMER and others.

Unix is too stupid, for real it has only 2 events, read and write. So for Linux almost all cases can be easily implemented with addRead/addWrite. BSD/MacOS is harder because we need to handle many flags, EVFILT_TIMER, EVFILT_PROC, EVFILT_SIGNAL, so we need to improve selectors module to hande all of this flags.

Windows is more flexible, but from my experience i'm always needed this IOCP handle.

@dom96
Copy link
Contributor

dom96 commented Oct 23, 2016

Even if it's not as useful for epoll/kqueue let's offer it. I like to keep the interface exposed by asyndispatch consistent across all operating systems.

@cheatfate
Copy link
Member Author

Your request will cause changes in selectors.nim, because descriptors of kqueue and epoll is hidden too.
But its not a big problem, but what i must do with plain select part of selectors.nim? And how people know what type of descriptor they are retreiving? epoll? or plain select? or kqueue?

@cheatfate
Copy link
Member Author

@dom96, i dont understand your problem.

When i ask you about this PR in IRC you answered "Sounds good", but when i'm pushing it, then you are not ready to accept it.

You know, i can easily close this PR, because i can use hack to achieve same result, but others no.

@dom96
Copy link
Contributor

dom96 commented Oct 24, 2016

Sorry, but just because I say "sounds good" in IRC does not guarantee that I will merge your PR.

This is a standard library and it requires some standards, if we add things on a whim without considering the implications we will end up with a standard library that is difficult to work with.

@cheatfate
Copy link
Member Author

I'm closing PR because of @dom96 position, which i cannot accept.

@cheatfate cheatfate closed this Oct 24, 2016
@cheatfate cheatfate deleted the getsystemhandle branch January 31, 2017 15:37
@cheatfate cheatfate restored the getsystemhandle branch January 31, 2017 15:40
@cheatfate cheatfate deleted the getsystemhandle branch January 31, 2017 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants