-
Notifications
You must be signed in to change notification settings - Fork 604
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
Scala Native #2975
Scala Native #2975
Conversation
This reverts commit 20a277a.
This reverts commit ea0c721.
I've published If anyone with an M1 wants to run the fs2-io test suite locally I'd be much obliged :) you will need to |
I tried on an M1 Mac and ran in to some test errors in TLSSockeSuite like this: ==> X fs2.io.net.tls.TLSSocketSuite.TLSSocket - google - default - client writes before reading 0.07s java.io.IOException: getaddrinfo: 8 |
@mpilquist thanks for that, probably due to broken IPv6 in epollcat. Hopefully the latest commit should fix that (or at the very least, give a more verbose error :) |
Just wanted to say you are a hero, @armanbilge! Thanks for all your work! |
Closes #2319.
Supports:
fs2-core
, excepthash
AsynchronousSocketChannel
is available at link-time, such as epollcatMost of the changes in this PR are adding support for TLS. Everything else is code shuffling.
The TCP implementation is unopinionated: it shares the
AsynchronousSocketChannel
implementation with the JVM.AsynchronousSocketChannel
is not implemented in Scala Native (and cannot be until it supports multithreading). This leaves the door open for 3rd parties to implement these APIs. Any implementation compliant with JDK should work.We run our tests against the implementation provided in epollcat which supports Linux and macOS. A hypothetical implementation of these APIs based on libuv and/or scala-native-loop could run on Windows.
On the other hand, the TLS implementation is very opinionated. It relies on s2n-tls and introduces configuration classes specifically based on its APIs and features. Note that s2n does not support Windows (aws/s2n-tls#497). s2n is also minimalist by-design:
In exchange, it offers a modern, simple API that was straightforward to integrate with. I think the trade-off is worth it.
The alternative, unopinionated approach would have been to use the JDK SSL APIs (essentially sharing the JVM code). These are not provided by Scala Native core, so it would be up to third parties to implement them. I explored this idea in sn-ssl, but it proves to be a significant amount of work with a greater surface area for vulnerability.
Once CI is green, I will publish a hash version to Maven Central and continue onwards to http4s ember and skunk.