Using the default implicit execution context in Scala, will each new future be computed on a single, dedicated thread or will the computation be divided up and distributed to multiple threads in the thread pool?
I don't know if this helps, the background to this question is that I want to perform multiple concurrent operations using the HtmlUnit API. To do this, I would wrap each new WebClient instance in a Future. The only problem is that the WebClient class is not thread safe, so I'm worried that it might broken up and sent to different threads.
One future is executed on a single thread. Several futures might be executed on several threads. So, no more than one future can occupy one thread simultaneously.
How does it work? When you create a Future it means that you've submitted task to your thread-pool - this one task can't be implicitly parallelized so it's executed on one thread only. One or several tasks submitted to the pool are being put into pool's queue, so executor takes tasks from that queue one-by-one and run each on some randomly (or intentionally) chosen thread. So several Futures may get to several threads.
About shared object - the only way to execute operations safely for object shared between futures is using Executors.newFixedThreadPool(1), it will use only one thread for the whole pool. Another solution - is to clone such object for every future. Using actors (make your shared object an actor's state) should be the best option.
If you use one object per future - everything should be fine.
Note: The future's handler, like Future{ ... }.map(handler) may be executed in different thread than the future itself, but it actually creates another Future to obtain a result. Same for flatMap. More precisely, they use onComplete which creates CallbackRunnable to launch handler (possible in different thread) after old future's success - this callback just completes newely created future, so still "no more than one thread per future"
A Future[+T] cannot guarantee that it will be completed on the same thread if its composed of multiple futures. That said, it doesn't mean that you'll get a concurrent modification exception or something along those lines. You can still get asynchronous code to execute sequentially, in which case it would be safe.
As for your second question, as long as you have one instance for each future you shouldn't have any concurrency issues.
