Future and Thread.

[Maatary Okouya]

Hi, 

by default, on which kind of Thread is a future executed ?

Example: 

when i run the following program

object ThreadAPP extends App {

  import scala.concurrent.ExecutionContext.Implicits.global

  val future = Future {

    println("done with the future"); "hello"

  }

  future foreach println

  //Thread.sleep(5000)

}

As you can see with the Thread.sleep commanted. or let say no await, the println is empty and the program terminate.

however with The sleep or an await, my main does not terminate. 

Hence, i wonder what is happening behind the scene. The Main thread in Java is supposed to be a daemon thread. (1) Is the future executed in a Deamon thread ? 

(2) Can an executorService manager both daemon (the main thread) and non-deamon (futures) at once? or the executorService of ....Implicit.global only create thread for whatever asynchronous code will come with future ?

If someone could explain a little how Implicit.global works that would help. 

[Jim Hazen]

This question is probably better asked on one of the Scala mailing lists.  You'll perhaps get a better answer.

To understand what is going on, take a look at the signatures for Future.apply and Future.foreach.  Each method has multiple parameter lists, with the last requiring (a possibly implicit) execution context.  The execution contexts past to these parameters will influence the behavior of the methods.  When you import scala.concurrent.ExecutionContext.Implicits.global you make the implicit val 'global' availble in your current scope.  Because this val is marked implicit, Scala will allow this val to participate in implicit resolution, following all the various rules for resolving implicits (better to get a book or ask a Scala list, since those rules are quite complicated).

So now with your Implicits.global import, your effective code looks like:

import scala.concurrent.Future

import scala.concurrent.ExecutionContext.Implicits.global

object ThreadAPP extends App {

  val future = Future {

    println("done with the future")

    "hello"

  }(global)

  future.foreach(println)(global)

  Thread.sleep(500)

}

So now it should be more obvious that your Future {} logic will be executed following whatever behavior global defines and the foreach behavior for how/when the foreach closure is called when the future completes is also determined by whatever the nature of global is.

So what's the nature of global?  The ScalaDocs don't give specifics.  A Scala mailing list might be able to clarify, and it might be documented somewhere within the language spec.  However, I think it's likely that this particular behavior simply isn't documented and could be subject to change.  A super quick demo like you've put together clearly demonstrates that these must be daemon threads behind the scenes, because they obviously don't prevent the termination of the VM.

Hopefully this removes some of the mystery and makes things more clear.

Your main thread is your main thread.  Each of your two Scala Future calls explicitly require an execution context, that you happen to resolve implicitly.  Your main thread is delegating work to an external execution context (global) and this appears to be using a thread pool backed by daemon threads.

[Maatary Okouya]

thanks for your input

btw correction

Hence, i wonder what is happening behind the scene. The Main thread in Java is supposed to be a non-daemon thread. 

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/5mHkRKFYvDc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Jim Hazen]

Correction?  I don't think I said main was a daemon, I said the Implicits.global executor must be.  In any case your main thread delegates to other executors.  Then, without the sleep, you run out of code and the VM exists. Because at that point main is dead and no other non-daemon threads are running.  So whether main was daemon or not doesn't matter, it's dead now.  You can then infer that Implicits.global must use daemon threads, *because* the VM exists.

Adding the Thread.sleep keeps the current thread (main) alive long enough for the other executors to execute.

[Viktor Klang]

Hi Maatary,

1) This is rather easily explored with the following incantation:

scala> Future { Thread.currentThread.isDaemon } foreach println
true

2) I am not sure I understand the question, would you mind elaborating?

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

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

[Maatary Okouya]

Jim i was correcting myself. the main thread in java per spec, in non-deamon.

everything is cristal clear now.

On Fri, Feb 13, 2015 at 12:52 AM, Jim Hazen <jimhaz...@gmail.com> wrote:

Correction?  I don't think I said main was a daemon, I said the Implicits.global executor must be.  In any case your main thread delegates to other executors.  Then, without the sleep, you run out of code and the VM exists. Because at that point main is dead and no other non-daemon threads are running.  So whether main was daemon or not doesn't matter, it's dead now.  You can then infer that Implicits.global must use daemon threads, *because* the VM exists.

Adding the Thread.sleep keeps the current thread (main) alive long enough for the other executors to execute.