jypma commented on issue #1801: URL: https://github.com/apache/pekko/issues/1801#issuecomment-2900023577
Moving `Task` into its own `task` module has hit a bit of a snag, due to the intent to not have the user provide a `Materializer` when creating a `Task` from a `RunnableGraph` (the `Materializer` is to be provided by `Runtime` once the task is actually executed). However, `Materializer` (obviously...) is in `stream`, so there's a dependency challenge here. We can go with `ActorSystem` instead of `Materializer`, giving us a few options: - Plan A: Keep `Task` in `stream` after all, since they are a fair bit intertwined - Plan B: Have `Task` in `task` module, make `Runtime` provide `ActorSystem`, and invoke `SystemMaterializer.apply` every time a stream is materialized (that's in effect a `ConcurrentHashMap` lookup in a typically very small map) - Plan C: Have `Runtime` maintain its own map of "extensions", now going for a simple non-concurrent immutable map reference (racing multiple created materializers is fine on startup). Would [B] have a measurable performance impact? I suppose if it end up it does, we can slip in [C] after the fact, too. What do others think here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
