[JBR]

I really wanted to translate some of the ideas in
[Coroutines for cooperative multitasking] to this page and use
the [interp limit] features to create a control structure that
would allow a master interpreter to run several slaves while
interrupting them when resources were exhausted (time or # of commands).
Then the slave procs could be resumed where they left off using the
coroutine command.

Conceptually the [interp limit] command callback would yield and some other 
code could be run.  The master could run its own code or call one of its 
slave coprocs, waiting for the limit command to yield again.

I didn't make it very far.  The fact that coroutines need to loop until
done (or forever) and the limit mechanism requires its command to return
after adjusting the interp limit seems incompatible.

Is this at all possible with our current coroutine and interp limit features?

----------------------------

Here is a bunch of chicken scratching that shows my lame attempt.


  #!/home/john/bin/tclsh8.6a2
  #

 namespace path ::tcl::unsupported

 set Tasks {}

 proc Task { task args } {
    interp create I$task
    interp eval   I$task proc p$task {} $args

    lappend ::Tasks $task
 }

 proc Drop { task } {
    set here [lsearch $::Tasks $task]
    set ::Tasks [lreplace $::Tasks $here $here]

    interp delete $task
 }

 proc Preempt { task commands } {
	interp limit I$task command -command $task
	set Max [expr [interp eval I$task info cmdcount] + $commands]

	interp limit I$task command -value $Max

	    yield


	    set Max [expr $Max + $commands]

	    interp limit I$task command -value $Max

	    puts "Return to $task"
 }

 Task one {} {
	while { 1 } {
		incr x
		puts "one $x"
	}
 }

 Task two {} {
	while { 1 } {
		incr x
		puts "two $x"
	}
 }


 proc PreemptiveRoundRobin  { commands } {
    foreach task $::Tasks {
	puts "coroutine $task Preempt $task $commands"
	coroutine $task Preempt $task $commands

	interp eval  I$task p$task
    }
 }

 # Run the two tasks 6 Tcl commands at a time
 #
 PreemptiveRoundRobin 6


----

[ferrieux] So you want Green Threads in Tcl too: I bow to your courage ;-) Now as to the implementation, what about using single-step execution traces instead of [interp limit] ? Of course it will be slower... but exec traces, contrarily to [interp limit], are not linked to an interp's end-of-life (assuming this is the problem; is it ?).

[JBR] We already have cooperative green threads, via coroutines.  Now I want a master thread to select and limit the execution of its slaves instead of just dispatching them.

[ferrieux] I know :) Matter of terminology here: by "green" I meant "userland", which includes both preemptiver and cooperative... But you didn't answer the suggestion about traces.

[MS] notes that forcing an interp to yield seems quite feasible to me (without having thought too hard about it). I lack the mental bandwidth at the moment to really think things through but: given well designed syntax and semantics (TIP quality), I volunteer to do the basic implementation. Ball's on your court :P

[NEM] can't answer the question as to whether this is feasible now with
[interp limit] -- perhaps [DKF] can answer definitively? It's an interesting
idea. The fact that it uses a single interpreter per "thread" would make it
seem rather similar to Tcl's native threading model. So the advantage would
presumably be that these threads are lighter-weight and so you can (a) run
more of them (if you have an extremely concurrent application), and/or (b)
there is less context-switching overhead. Is that the idea? (I'm not entirely
sure about (b) -- is a coroutine switch cheaper than an OS level context switch?)

----
!!!!!!
%| [Category Concept] |%
!!!!!!