Rename execution contexts + improve their docs #15936
Conversation
Co-authored-by: Johannes Müller <[email protected]>
Co-authored-by: sbsoftware <[email protected]>
straight-shoota
left a comment
straight-shoota
left a comment
There was a problem hiding this comment.
As mentioned in #15946 (comment), I think we should keep the old names as aliases.
Even though we can't use the @[Deprecated] annotation, it at least avoids a hard break between 1.16 and 1.17, which is unpleasant if you want to test code with both releases, and maybe some nightlies in between.
|
EDIT: I added the deprecated aliases. See below. |
straight-shoota
added
topic:stdlib:concurrency
kind:breaking
The execution context feature is experimental but having an upgrade path is nicer than an abrupt compilation error. The actual deprecation warnings shall only appear in Crystal 1.18.
|
#15962 won't make it into 1.17 due to the feature freeze. We could still merge this PR though because it only affects execution contexts, which are still an experimental API. |
|
@straight-shoota yes, we'll have deprecations in nightly then 1.18, and we can drop them in 1.19 👌 |
|
Should we update RFC0002 doc for this? |
4 participants
As discussed in RFC 2 and in light of #15871 for example, the execution contexts are much more about "how fibers run", either concurrently or in parallel or by themselves (the intent), and have little to do with "threads" that are only the technical mean to achieve parallelism.
A great example is that the isolated context doesn't have the word thread in its name, despite being the only context that guarantees the fiber will always run on the same thread (the fiber owns the thread until it terminates).
This PR renames:
SingleThreadedtoConcurrentMultiThreadedtoParallelIt also refines the documentation of the different types to also insist on the intent, what it means, and what are the actual guarantees given by each context.