Mike, Thanks so much for teaching us some things.
On Thu, Jul 19, 2018 at 1:20 PM, Michael Comella <mcome...@mozilla.com> wrote: > 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> > I was concerned about this, for slightly different reasons: I care about the same thread of execution servicing the next FFI call, i.e., that FFI calls don't rotate between threads non-deterministically. But I think it's very similar to the situation you warn about. I took an action item to read more about Kotlin co-routines, and summarized (in the notes) like this: - AI: nalexander to read more about how Kotlin coroutines are implemented - [nalexander] OK, I’ve done this. Based on the Kotlin 1.1+ coroutines documentation <https://kotlinlang.org/docs/reference/coroutines.html>, Kotlin coroutines are implemented as a CPS transformation and an internal state machine. That state machine is pumped from a single thread. That’s very similar to clojure/core.async <https://github.com/clojure/core.async> and means that there’s no thread pool servicing coroutines! Any additional thread must be the result of the application (or a library). That means that all my hypothetical concerns about coroutines invoking FFI methods on multiple threads are not justified. Am I incorrect? Please correct me if so! 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/>) > I agree that `CommonPool` can cause issues. (Just for the record, I had not heard of `CommonPool`.) But to me, those issues are clearly _above_ the Rust FFI layer, and the _common_ part of the name is pretty clear that applications and libraries need to coordinate in order to prevent bad things (in this case, limiting throughput due to resource starvation, or, in the worst case, livelocking). Coming back to my summary of how Kotlin coroutines are implemented, something above the Rust library layer has to handle adding asynchrony to the synchronous Rust -- either by spawning threads (with a pool, common or otherwise, if desired); or by doing non-blocking things where possible; or ... Are we in accord? Nick
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
