Trampoline execution context

261 views
Skip to first unread message

grenvill...@gmail.com

unread,
Sep 5, 2016, 1:45:32 AM9/5/16
to scala-internals
Hi,

Let me know if this is the wrong place to post this - the contribution guide pointed me to this mailing list. I've also tried searching both the Scala JIRA and this list's archives for this idea, but it looks like it hasn't been mentioned before.

How would people feel about adding a trampoline execution context to the standard library, like the one used by Play? I ask because a number of projects have implemented their own version (not only Play, but also Slick and Monix) and it seems that it'd be nice if a single, definitive instance was provided. It'd also be useful for any developer who maps cheap operations over Futures and doesn't want to have to schedule a Runnable on a thread for each one. Do you think this is something Scala would benefit from?

Thanks,
Grenville Wilson

Viktor Klang

unread,
Sep 6, 2016, 4:41:46 PM9/6/16
to scala-i...@googlegroups.com
Hi Grenville,

Thanks for reaching out

the stdlib already has such a thing but it isn't exposed to end-users: https://github.com/scala/scala/blob/2.12.x/src/library/scala/concurrent/BatchingExecutor.scala


The BatchingExecutor is used internally in the Future implementation to trampoline safe operations to trampoline.

We have hesitated in exposing it as a general thing since it can *very easily* wreak having for *synchronous implementations*.

That being said, I think it would be interesting to see if it makes sense to expose BatchingExecutor, especially if we can minimize the risk that someone uses it inappropriately by mistake.

With 2.12 the recommended (by me) approach is to use transform and transformWith and create transformations Try => Try if you want to optimize for "not scheduling Runnables".

Would love to hear your thoughts on that,

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Cheers,
√

Naftoli Gugenheim

unread,
Sep 6, 2016, 6:16:19 PM9/6/16
to scala-i...@googlegroups.com

One possible middle ground is to make it publicly accessible, but don't include an implicit val that someone could unintentionally import.


To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Cheers,
√

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

Viktor Klang

unread,
Sep 7, 2016, 12:39:53 AM9/7/16
to scala-i...@googlegroups.com

Are we talking about an async, or a sync, trampolining EC?

--
Cheers,
√


On Sep 7, 2016 12:16 AM, "Naftoli Gugenheim" <nafto...@gmail.com> wrote:

One possible middle ground is to make it publicly accessible, but don't include an implicit val that someone could unintentionally import.


On Tue, Sep 6, 2016, 4:41 PM Viktor Klang <viktor...@gmail.com> wrote:
Hi Grenville,

Thanks for reaching out

the stdlib already has such a thing but it isn't exposed to end-users: https://github.com/scala/scala/blob/2.12.x/src/library/scala/concurrent/BatchingExecutor.scala


The BatchingExecutor is used internally in the Future implementation to trampoline safe operations to trampoline.

We have hesitated in exposing it as a general thing since it can *very easily* wreak having for *synchronous implementations*.

That being said, I think it would be interesting to see if it makes sense to expose BatchingExecutor, especially if we can minimize the risk that someone uses it inappropriately by mistake.

With 2.12 the recommended (by me) approach is to use transform and transformWith and create transformations Try => Try if you want to optimize for "not scheduling Runnables".

Would love to hear your thoughts on that,
On Mon, Sep 5, 2016 at 7:45 AM, <grenvill...@gmail.com> wrote:
Hi,

Let me know if this is the wrong place to post this - the contribution guide pointed me to this mailing list. I've also tried searching both the Scala JIRA and this list's archives for this idea, but it looks like it hasn't been mentioned before.

How would people feel about adding a trampoline execution context to the standard library, like the one used by Play? I ask because a number of projects have implemented their own version (not only Play, but also Slick and Monix) and it seems that it'd be nice if a single, definitive instance was provided. It'd also be useful for any developer who maps cheap operations over Futures and doesn't want to have to schedule a Runnable on a thread for each one. Do you think this is something Scala would benefit from?

Thanks,
Grenville Wilson

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
Cheers,
√

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

Grenville Wilson

unread,
Sep 7, 2016, 10:17:44 PM9/7/16
to scala-i...@googlegroups.com

Using transform and transformWith works when you have total control over the Futures in question. However, when composing queries in Slick you pass in an ExecutionContext which Slick then uses to compose its DBIO instances - often using map, flatMap, filter, etc. Other libraries have similar situations, where the caller only has the ability to pass in an ExecutionContext and no ability to control what's done with it.

I do agree that if introduced, this should not be an implicit value. We wouldn't want people importing and using this unless they knew what they were doing. Mainly the library writers who currently have to create their own versions, IMO.

I'm not sure what an async trampoline EC would look like - would that be the like the stdlib BatchingExecutor, which batches Runnables and defers execution to another EC? I was more thinking of what I've seen from Play/Slick/Monix, a trampolined version of Guava's MoreExecutors.sameThreadExecutor(), but there's obvious dangers to a misused synchronous ExecutionContext.

You received this message because you are subscribed to a topic in the Google Groups "scala-internals" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-internals/QgtKugpqUlk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-interna...@googlegroups.com.
signature.asc

Viktor Klang

unread,
Sep 8, 2016, 2:55:48 AM9/8/16
to scala-i...@googlegroups.com

I'd say passing in a synchonous trampolined EC to 3rd party code is probably the least best use case. As a user you havr no idea what that 3rd party is going to do, which is why async trampolined is preferable.

--
Cheers,
√


To unsubscribe from this group and all its topics, send an email to scala-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages