redo ActorSystem’s management of Threads and Executors
- Dispatcher receives an ExecutorDelegate from the ActorSystem, which it activates for inhabitants>0 and deactivates otherwise
- ActorSystem deals out these EDs keeping track of them and has a period task running which can decommission ones which have been inactive for some time
- our ThreadFactory creates threads in a new ThreadGroup
- shutdown sequence is changed according to the attached flow diagram, where the Thread which runs the cleanup may well be the same thread that is used internally by the Scheduler (we then would mandate implementations to tell that thread to shutdown upon close() and require them to run ActorSystem.finishTermination() or some such.
- termination tasks may be modeled using a suspendable single-threaded ExecutionContext, which has tasks queued during the ActorSystem’s lifetime and uncorks the queue at shutdown time, running things strictly FIFO
- if things take too long we have a scheduled timer task which will Thread.stop() our thread group (leaving out the timer, of course)
- termination tasks are started by the rootGuardian, not outside of the actor system proper
Leave a comment
on 2013-01-24 12:20 *
By rkuhn
Assigned to set to login
Description changed from * get rid of LazyExecutorSe... to * Dispatcher receives an Ex...
Estimate changed from Medium to Large
Summary changed from disentangle Scheduler and Dispatcher to redo ActorSystem’s management of Threads and Executors
Sum of child estimates changed from 4.0 to 8.0