Open lxbndr opened 1 year ago
@lxbndr I'd suggest you use https://github.com/swift-server/async-http-client instead of FoundationNetworking on Linux. On Linux, it has many issues and most users use AsyncHTTPClient which also works much more nicely with async/await (the async extensions for URLSession are Darwin-only right now).
I came back to see if any progress had been made in this area... You still cannot use URLSession on Windows without the threat of a crash, unfortunately...
@gregcotten unfortunately, yes :( I had some intermediate results, but not something worth to commit yet. But hey, this is not abandoned. There is real need in fixing this, in production, so I am planning to invest some effort into this soon.
I just wanted to lend my voice to this conversation as I was reminded about this issue as I was extending a third party library to support Windows. This issue is a pretty large problem when trying to approach Swift in a portable fashion. @weissi does async-http-client work on Windows?
I just wanted to lend my voice to this conversation as I was reminded about this issue as I was extending a third party library to support Windows. This issue is a pretty large problem when trying to approach Swift in a portable fashion. @weissi does async-http-client work on Windows?
Definitely not - swift-nio needs a Windows networking champion to make that happen.
Does anyone have test cases they can share on this issue so that we might make this a bit of a starting point for people looking to try to tackle this problem? @lxbndr would you be able to share any patches/code you've created while trying to work with this issue?
The basic crashing sample is here. Depending on the target host behavior you would get one of two kinds of crash.
_MultiHandle
will get invalid (closed) socket handle from cURL, and Dispatch would crash trying to work with that handle. We have no workaround for this other than suppressing crashes in Dispatch, unfortunately. Also, cURL version was bumped since then, so this have to be re-checked.I believe I had a test sample for socket handle value reuse issue, but can't find it anywhere. Basically, I just repeated same (normal, not timeout) request in cycle. Every new request is started in URLSession's completion handler of previous request, and socket reuse appears almost immediately.
Also, I have to mention the fix for non-Windows platforms our Android team made: https://github.com/readdle/swift-corelibs-foundation/commit/017ceb01fad4d2a46a27981a9e4722e844d04b71 This looks better to me, as we don't have to play with queues. But AFAIK we can't apply this to Windows, as sockets there are different by nature.
The problem is pretty old and has been reported in Dispatch initially. After the investigation, it appears that it has to be fixed in Foundation. I am opening this issue for tracking and sharing the progress.
Background
URLSession utilizes cURL for socket management, including reading, writing, and basic protocol operations. cURL, in turn, requires external notification when there is pending data or an event on a socket. This is where
DispatchSource
comes into play. The implementation ties the lifecycle of aDispatchSource
to the register/unregister requests from cURL.The Issue
When cURL requests
_MultiHandle
to unregister a socket, the_SocketSources.tearDown
function is implicitly called. This function invokesDispatchSource.cancel()
and immediately returns control to cURL. Right after that cURL closes the socket. The Dispatch documentation saysDetails
Although this violation is common for all platforms, it seems that Windows is the most severely impacted. It is crucial not to close the socket too early, as doing so could result in Windows reusing the freed socket handle for a new connection. This, in turn, may lead to Dispatch handling the same socket simultaneously as both dead and alive. Also, Dispatch proactively checks for invalid sockets in critical locations (like this) and crashes immediately if an invalid socket handle is encountered. Therefore, it is highly important to prevent the socket from being closed until Dispatch has finished its operations.
The simplest crashing scenario is HTTP timeout (originally reported here). You will get crash immediately as the timeout handler removes
_EasyHandle
from_MultiHandle
. Trying to mute the crash (by ignoringWSAENOTSOCK
error, as proposed here) reduces the crash rate, but leaves us open to much more cryptic crashes due to socket handle reuse.Possible Solutions
Obviously, we have to wait for cancellation handlers, but it is a bit tricky to implement. URLSession is designed to process network events on a single queue. Cancellation handlers are also submitted on that queue. We can't just wait for a callback, because it would be an effective deadlock.
_MultiHandle
.DispatchSource
close handler is triggered, it can search the list for any "close pending" sockets and then proceed with the actual closure.Additional Case
There is a real scenario when cURL still closes the socket internally (ignoring the custom close function) and passes us an already closed socket. It's unclear whether this is a bug in cURL or a valid case that may require a client-side workaround. We probably should solve that separately.
Next Steps