-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
OS_SOCKET is exported but only defined on windows (also a bad name) #3020
Comments
I agree that we need a better interface and that the names are bad, but I disagree in this case that it shouldn't be exported. After all, the API we are dealing with here is precisely used to interface with low-level platform specific libraries. The fact that Windows has two kinds of file descriptors, while Unix only has one is unfortunately a fact of life. |
It's an unfortunate fact that we should be hiding from Julia programmers, not foisting on them. |
Sure, but not from those Julia programmers who want to monitor raw OS FD's, which is what this API is doing. |
It should be called something like |
The poll_fd interface seem to me to be wrapping too much. Perhaps there should be a RawFD object (which knows whether it is a socket or file -- name can be changed) which participates in the I've been thinking it would be nice to export the Jeff's code block suggestion seems even better to me, with one caveat: it seems to me that the yield needs to be an explicit part of the waitfor call and not the task state. Otherwise you aren't allowed to call any potentially blocking call between calling waitfor and yield (such as
I tried to make this a single blocking call to extend my first suggestion above, but it seemed to lose much of its flexibility, including the ability to use named arguments, so I like the object-based approach better. |
+1 for absorbing |
+1 for a single For example:
|
Bump |
Working on it. |
Something that only exists on one platform is an implementation detail that shouldn't be exported.
Even if it existed everywhere, I still wouldn't want to write
OS_SOCKET
in my code. I'm also suspicious ofOS_FD
,UV_READABLE
, andUV_WRITEABLE
. An API is supposed to provide abstractions; we can talk about readable and writeable, but not UV, and not in all uppercase. For example,poll_fd(fd, tout, readable=true)
would be ok. Aside from those detailspoll_fd
seems like a good interface.But I'm less sure about the likes of
FDWatcher
andstart_watching
.poll_fd
seems to already provide the most useful tasks you can do with those. And if you need something else, you are up a creek, because you'll need a detailed incantation ofWaitTask
,FDWatcher
,start_watching
,TimeoutAsyncWork
,start_timer
,yield
, andstop_watching
.Maybe we could have something like:
where
waitfor
sets up the current task to wait for something when it next yields. Combining all of these into a single blocking call would be fine too. Point is, it would be nice to express all the things you can wait for in a uniform way (RemoteRef
refactoring is allowed too).The text was updated successfully, but these errors were encountered: