Add sameThread to scala.concurrent.ExecutionContext.Implicits

Scala Standard Library
1

This should be very useful and instead to not only suggest the global one.

like Future#map(identity)

1 Like
2

That would probably not be a good idea, because a general-purpose ExecutionContext must be asynchronous. From https://www.scala-lang.org/api/current/scala/concurrent/ExecutionContext.html:

A general purpose ExecutionContext must be asynchronous in executing any Runnable that is passed into its execute-method. A special purpose ExecutionContext may be synchronous but must only be passed to code that is explicitly safe to be run using a synchronously executing ExecutionContext.

Most APIs are not “explicitly safe to be run with a synchronous executing EC”.

3

Yes, but some do. otherwise we may need to craft one.

4

I also agree it is not a good API to provide. We have such in Akka but it is internal API and only to be used “exactly when you know what you’re doing”.

Also, if the worry is about “in order to improve Future performance”, then rather improving Future is the goal and ongoing with great results over here https://github.com/viktorklang/scala-futures/ rather than exposing a dangerous API in Scala itself.

1 Like
5

yes,I agree this will open the bugs can

1 Like
6

It would be great if we could add a sameThread EC to ExecutionContext, but I fear it would lead to more problems than it solves.
We could move the internal callback executor from Future to EC, but we’d have to document the drawbacks, and possibly name it something which highlights the dangers. Not sure if it is worth it, but perhaps better than having people implement such ECs poorly.

Open to be convinced

7

I open up this issue because when we are moving our applications to Reactive at（Taobao, a company of Alibaba group), and found that we have to shift the executor now and them (not totally reactive) some part the blocking one is running in a coroutines pool (Which did not give us many gains, a system only get 7 % boosts and after moving to Reactive, increase 96.2 %). When we tunning an internal library we found that it uses the global one here and there…, and then we move to the same thread one.

So I think when we do not suggest using the global one and should choose the EC wisely, and add a same thread one in contrast to the global one.

Back to the Java’s CompletableFuture, it always has an explicit Async one there to mentor you.

8

But I still concern that, if we add the same thread one, then we do need a trampoline one :(,and all are buggy sometime.

9

I still think that，If we add some default ones and well document them, then that will do helps a lot, there is comparison then there is wisely choose.

10

I think deprecating ExecutionContext.Implicits is the right way to go. (especially for sameThread/trampolining ECs you want to specify it explicitly)

What would a sameThread/trampolining EC need to be named in order to reduce risk of foot injuries?