AndreVanDelft / scala

The SubScript extension to the Scala programming language
http://www.subscript-lang.org/
12 stars 1 forks source link

Strange behaviour of the debugger with SubScriptActors #22

Open anatoliykmetyuk opened 10 years ago

anatoliykmetyuk commented 10 years ago

Consider following program:

  class SimpleActor extends SubScriptActor {
    def script live = {println("I exist")}
  }

  def main(args: Array[String]) {
    val as = ActorSystem()
    for (_ <- 1 to 10) as actorOf Props[SimpleActor]
  }

Now, if you run it without a debugger (with abt run), everything happens as expected. You get 10 "I exist" messages at the console in every run. However, if you run it with a debugger (abt debug), strange things happen. First, even before "Step" button is clicked, there's a random amount (up to 10) of "I exist" messages at the console (this means, SubScript VM starts some processing without being blocked by the debugger). Second, not every actor is spawned. Some InvokeFromET messages (used to dynamically and sequentially activate subscript actors templates from the main graph) are observable in the message queue (also random amount of them), but it's often the case that debugger doesn't process them, simply saying "Waiting" in the current message window when it's time to process them.

I suppose that somehow it is related to the dynamic nature of actor templates activation.

AndreVanDelft commented 10 years ago

The current SubScriptActor implementation depends on a hack in the call graph to start actor live scripts. This is highly dubious; I would certainly not trust the debugger to deal with this.

Therefore I have now implemented process launching. Syntax: (* process *) - launch a process, comparable with process& on the Unix command line. (** anchor **) - a node onto which launched processes are anchored

A launched process is anchored to the nearest anchor node. The root node of a ScriptExecutor is an anchor node, so there is always one available.

It is also possble to launch processes by calling the method launch on the here variable, with a script lambda as a parameter. The following expressions are equivalent:

(* process *)
{! here.launch([process]) !}

Another issue: We should consider to let Akka run the SubScript VM. Then the VM's run method should not be called any more (once), but instead the Akka scheduler would need to call workToDo() every now and then.