Thanks for the updates, Nick – it's interesting to hear what other teams are doing and how it may affect me. :) One quick thought:
> Rust code should be synchronous I haven't thought about this enough to have an opinion on whether this is the right decision or not. However, this may encourage the Rust library consumers to make a mistake I once made with Kotlin coroutines: *I want to share so others don't make the same mistake.* While you can create an obscenely large number of coroutines, there is a limit to the number that can run concurrently: this limit is defined by the thread pool they run on. The default built-in `CommonPool` has a fixed number of threads. If you run blocking code (e.g. potentially synchronous Rust code ^) on this thread pool, i*t prevents other coroutines from beginning to run* until the blocking code completes. Here's a demonstration using Android. <https://github.com/mcomella/BlockingCoroutinesExample> Why is this a problem? *If you're a library (e.g. android-components) that uses the same fixed thread pool as the application, you may block the application's coroutines from starting quickly!* For example, if the library makes several calls to read configuration files from disk, each on a new coroutine on the CommonPool, these may block all of the CommonPool threads. If all the threads are blocked and the application spawns a coroutine on the CommonPool to do background processing before rendering the results in the UI, the application's coroutine (and thus the UI update) will wait until the library's coroutines finish blocking before it runs. --- Some possible solutions to this are: - Use a separate thread pool for blocking calls (here's an open ticket for a system-wide IO thread pool <https://github.com/Kotlin/kotlinx.coroutines/issues/79>) - Use non-blocking IO (supported in Java 7+ with nio <https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-nio/>) Hope it helps! - Mike On Wed, Jul 18, 2018 at 8:28 PM Nicholas Alexander <nalexan...@mozilla.com> wrote: > We had a Mobile Tech Leads Meeting earlier today (NA/AU timezones). Due > to PTO, it was a smaller group than usual. > > A very brief and opinionated summary of our discussion (from this doc > <https://docs.google.com/document/d/13ZqcDtmedjAykVveOlZSFYP5tWi2i6G5dCzUuHEBY0U> > ): > > 1. *How do we manage threading* between consumers (primarily Android > invoking Rust from Java/Kotlin, but also iOS invoking Rust from Swift) and > Rust libraries? > - Discussion focused on JVM thread pools and Kotlin coroutines. > - Strong desire to not expose concurrency in the API surface > - Initial proposal, subject to much further discussion: > - > *Rust code should be synchronous * > - *Rust code should expect to be invoked from multiple threads* > - *Rust code should expect to be serialized (via Java > `synchronize` keyword or equivalent)* > 2. There was some discussion of dependency injection for logging > and telemetry. > - markh will be leading that discussion for telemetry. > > There's more in the notes but that's the gist. > > Your interlocutor, > Nick > > _______________________________________________ > android-components mailing list > android-compone...@lists.mozilla.org > https://lists.mozilla.org/listinfo/android-components >
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
