-
Notifications
You must be signed in to change notification settings - Fork 521
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 #3057
Scala Native #3057
Conversation
@extern | ||
@nowarn | ||
private[std] object sysrandom { | ||
def getentropy(buf: Ptr[Byte], buflen: CSize): Int = extern | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works on Linux and macOS. I reckon that's plenty good for now. Anyone can implement SecureRandom
for themselves to suit their requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely need to write up some serious words about the limitations of the current implementation. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. But note that anyone who tries to use this on an unsupported platform will get an error at linking time, before runtime. So it's not evil, just annoying.
.nativeSettings( | ||
libraryDependencies += "io.github.cquiroz" %%% "scala-java-time" % "2.4.0" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think Scala Native has the same artifact size concerns as Scala.js, so I reckon we should ship java.time
support out-of-the-box.
def blocking[A](thunk: => A): IO[A] = | ||
apply(thunk) | ||
// do our best to mitigate blocking | ||
IO.cede *> apply(thunk) <* IO.cede |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Downstream libraries are riddled with blocking calls (e.g. DNS resolution in ip4s, file I/O in fs2). Actually even IO.println
is blocking! Since we don't have a blocking threadpool to run them on, this seems like the best we can do to mitigate their effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually we can do even better here: this should be apply(thunk).guarantee(IO.cede)
. We don't want to skip that cede
even if we errored.
Now behaves like `ScheduledExecutorService#setRemoveOnCancelPolicy(true)` used on JVM
This reverts commit 7efbac0.
So this is all in |
No, this is not really in Yes, sorry, not ideal. But I wasn't prepared to let this die-on-the-vine like my |
whistles innocently Either way, given that this has now been released, I think it's best if we get it into series/3.x to form a part of 3.4. :-) |
Ok, @djspiewak, let's land this one :) tbh I was quite sad to ship this out in 3.3.14 without your review, so I'm looking forward to that 😇 Question: do we want to add a macOS CI job? There a couple places where we directly call native APIs (high-precision time and cryptographically strong random numbers). They are all supported on Linux/macOS, but in theory we should be careful. |
I hate to say it, but we should be careful. :-( So that means one more matrix entry. |
Something I haven't done in this PR is setup the test harness so we can run the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly just worried about the lack of documentation and caveats!
lazy val keepAlive: IO[Nothing] = | ||
IO.sleep(1.hour) >> keepAlive |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually need this with Scala Native?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe so! The whole point of this is to keep an IO.never
program alive. In the IO.never
case the EC queue will be empty. In theory we could just have the main thread go into a permanently parked state in this situation.
But in practice the EC actually has to stop running if its queues are empty so that it can yield to the Scala Native global EC, to make test frameworks work correctly. See also the doc comment on poll(...)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fascinating. It's identical code but actually handled in an entirely different way.
def blocking[A](thunk: => A): IO[A] = | ||
// do our best to mitigate blocking | ||
IO.cede *> apply(thunk).guarantee(IO.cede) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😱
import scala.concurrent.CancellationException | ||
import scala.concurrent.duration._ | ||
|
||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we write some words in here which clarifies 1) the experimental nature of things, and 2) the limitations imposed by this particular IOApp
? It's fair to call out to EpollCat for now since that's the only usable runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep can write some doc. Besides the blocking
issue I wouldn't really say IOApp
is limited. Anything you can do in Scala Native today works fine with this IOApp
. If you want to do async I/O with JDK APIs, tough, because they are not implemented anyway, but that's not this IOApp
s fault.
It's fair to call out to EpollCat for now since that's the only usable runtime.
It's not actually. It's only necessary for fs2.io.net
and thus ember or skunk etc.
I have a CurlApp
in http4s-curl that's perfectly good if the only non-blocking I/O you need are HTTP requests (this is sufficient to implement a Lambda runtime btw). Also that runtime is theoretically capable of polling on arbitrary file descriptors, but I have not exposed that.
I also just wrote an io_uring
-based runtime in armanbilge/fs2-io_uring#2. But that's still a bit premature :)
Finally, see also #3153 (comment) where we discussed some interesting native applications built with vanilla IOApp
, including CLIs and an LSP.
@nowarn("msg=never used") | ||
def calculateTracingEvent(key: Any): TracingEvent = null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be fun™…
@extern | ||
@nowarn | ||
private[std] object sysrandom { | ||
def getentropy(buf: Ptr[Byte], buflen: CSize): Int = extern | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely need to write up some serious words about the limitations of the current implementation. :-)
package cats.effect | ||
|
||
trait DetectPlatform { | ||
def isWSL: Boolean = System.getProperty("os.version").contains("-WSL") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are system properties handled on Scala Native?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea what this would say for WSL. But I believe it does attempt to populate them as the JVM would.
Closes #1302.