- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Actors and threads
Sat, 2009-05-16, 20:51
I found out, quite by accident, that actors (whether "react" or "receive"
actors) are run in daemon threads. This situation makes sense, now that I
think about it, though it was a surprise at the time.
I'm working on an application that uses actors as an easy way to parallelize
some work. Unlike a server, this application is not long-lived. It comes up,
fires up some actors to do some work, and goes away when the actors complete.
While testing the application, I found that it would often end before the
actors complete, and not always in the same place. When I discovered that the
actors are all running as daemon threads, that behavior suddenly made sense.
I can kludge around the issue by spawning a non-actor, non-daemon thread that
waits on a semaphore and gets awakened when the last actor completes. Then,
the main program can simply join that non-actor thread.
However...
In my application, I can easily ensure that one actor is a thread-based
"receive" actor. Thus, I know it will have its own dedicated thread. Is there
a way to ensure that such an actor runs in a non-daemon thread? Being able to
do so would simplify my code.
The documentation isn't clear (at least not to me). I'm poking through the
actor library source, to try to find an answer, but it's possible someone on
the list already knows.
Thanks in advance.
Mon, 2009-05-18, 23:17
#2
Re: Actors and threads
2009/5/16 Brian Clapper <bmc@clapper.org>
Which is exactly why using daemon threads is a poor decision, particularly as the default option. I hope this will be addressed if the Actor library is rewritten.
I found out, quite by accident, that actors (whether "react" or "receive"
actors) are run in daemon threads. This situation makes sense, now that I
think about it, though it was a surprise at the time.
While testing the application, I found that it would often end before the
actors complete, and not always in the same place. When I discovered that the
actors are all running as daemon threads, that behavior suddenly made sense.
Which is exactly why using daemon threads is a poor decision, particularly as the default option. I hope this will be addressed if the Actor library is rewritten.
Tue, 2009-05-19, 12:17
#3
Re: Actors and threads
This actually shouldn't happen with the current implementation. The worker threads are all daemons, but the scheduler also has it's own thread which by default is not daemon. ActorGC takes care of shutting down the scheduler thread when there are no more active actors.
Brian - Could you open up a ticket in Trac with a simplified version of your code? This sounds like a bug.
On Mon, May 18, 2009 at 6:14 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
--
http://erikengbrecht.blogspot.com/
Brian - Could you open up a ticket in Trac with a simplified version of your code? This sounds like a bug.
On Mon, May 18, 2009 at 6:14 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
2009/5/16 Brian Clapper <bmc@clapper.org>I found out, quite by accident, that actors (whether "react" or "receive"
actors) are run in daemon threads. This situation makes sense, now that I
think about it, though it was a surprise at the time.While testing the application, I found that it would often end before the
actors complete, and not always in the same place. When I discovered that the
actors are all running as daemon threads, that behavior suddenly made sense.
Which is exactly why using daemon threads is a poor decision, particularly as the default option. I hope this will be addressed if the Actor library is rewritten.
--
http://erikengbrecht.blogspot.com/
Tue, 2009-05-19, 12:27
#4
Re: Actors and threads
On 5/19/09 7:11 AM, Erik Engbrecht wrote:
> This actually shouldn't happen with the current implementation. The
> worker threads are all daemons, but the scheduler also has it's own
> thread which by default is not daemon. ActorGC takes care of shutting
> down the scheduler thread when there are no more active actors.
>
> Brian - Could you open up a ticket in Trac with a simplified version of
> your code? This sounds like a bug.
I'll see if I can reproduce it with a simplified tester. If so, I'll open the
issue. Thanks for the response.
Fri, 2009-05-22, 23:07
#5
Re: Actors and threads
On 5/19/09 7:11 AM, Erik Engbrecht wrote:
> This actually shouldn't happen with the current implementation. The
> worker threads are all daemons, but the scheduler also has it's own
> thread which by default is not daemon. ActorGC takes care of shutting
> down the scheduler thread when there are no more active actors.
>
> Brian - Could you open up a ticket in Trac with a simplified version of
> your code? This sounds like a bug.
I'm pleased to say that this problem turned out to be programmer error
(specifically, some inappropriate exception handling on my part), as I found
out when attempting to write a simpler test to reproduce the problem.
Sorry for the false alarm.
On Sun, May 17, 2009 at 7:51 AM, Brian Clapper wrote:
> In my application, I can easily ensure that one actor is a thread-based
> "receive" actor. Thus, I know it will have its own dedicated thread. Is there
> a way to ensure that such an actor runs in a non-daemon thread? Being able to
> do so would simplify my code.
Hi Brian
If you create the thread yourself, and call only 'receive' (not
'react') within that thread, then you can be sure that actor will use
only that thread. For example, when I'm doing unit testing on actors,
I always run the tests in new actors and use 'receive' on the main
test thread to wait for a result. The new actors will be scheduled
into threads somehow, and I can use 'react' within them, but I don't
have to worry how this happens.
Cheers
Rich
--
http://blog.richdougherty.com/