Conversation
|
Originally discussed in #423. |
| socketToFd s = do | ||
| fd <- unsafeFdSocket s | ||
| -- FIXME: throw error no if -1 | ||
| fd2 <- c_dup fd |
There was a problem hiding this comment.
[ IIRC, on windows INVALID_SOCKET is not -1 since SOCKET are unsigned on Windows. ]
Also, AFAIK, Windows does not have dup(2) for sockets, but it does have DuplicateHandle().
So making this portable requires may require some special-casing for Windows, unless suitably
special-cased wrappers are already available.
That said, yes, this is the general idea.
There was a problem hiding this comment.
Mysteriously, AppVeyor can build this: https://ci.appveyor.com/project/kazu-yamamoto/network/builds/27135892
There was a problem hiding this comment.
@Mistuke Would you suggest a proper way on Windows?
There was a problem hiding this comment.
I actually think this may work fine. DuplicateHandle() is not correct for Sockets, it's explicitly called out not to do so on it's documentation page https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-duplicatehandle
You should not use DuplicateHandle to duplicate handles to the following objects:
* I/O completion ports. No error is returned, but the duplicate handle cannot be used.
* Sockets. No error is returned, but the duplicate handle may not be recognized by
Winsock a the target process. Also, using DuplicateHandle interferes with internal
reference counting on the underlying object. To duplicate a socket handle, use the
WSADuplicateSocket function.
and also on the docs for Socket handles https://docs.microsoft.com/en-us/windows/win32/winsock/socket-handles-2.
But reason I think this may work is because on that same page it says
A socket handle can optionally be a file handle in Windows Sockets 2. A socket handle
from a Winsock provider can be used with other non-Winsock functions such as
ReadFile, WriteFile, ReadFileEx, and WriteFileEx.
So a socket can be a file handle in Winsock2, unsafeFdSocket is a call to _open_osfhandle which will return a descriptor for any system file handle, so should work with sockets. and so dup should work..
So easiest way is to test it and see.
There was a problem hiding this comment.
Do you mean we should merge this PR and release a new version and see what will happen?
There was a problem hiding this comment.
no, I mean write a simple test to see if the fd returned by this is usable. I can also use that to check if the associated kernel object's refcount decreases when you close it.
There was a problem hiding this comment.
I can do both for you if you want but it'll have to wait for the weekend :)
There was a problem hiding this comment.
No problem. I can wait. Thanks in advance!
ab0c05a to
e7312bb
Compare
| touch ref | ||
| return r | ||
|
|
||
| -- | Socket is closed and a duplicated file descriptor is returned. |
There was a problem hiding this comment.
The documentation can then say, that the duplicated descriptor is no longer subject to the possibility of unexpectedly being closed if the socket is finalized. It is now the caller's responsibility to ultimately close the duplicated file descriptor.
There was a problem hiding this comment.
Thanks and done.
47885df to
d0bba03
Compare
|
@Mistuke Ping. |
|
Ah sorry! , was/am away for work. I'm traveling back today and will take care of this tomorrow after I land. |
|
This should work for Windows |
Credit: Tamar Christina <[email protected]>
|
@Mistuke Thank you for your excellent work! This PR has been merged. |
@vdukhovni This is a PoC. I'm not sure that this implements what you want. Please give me your advice.