9fans,
FYI, I've wondered if they had the same problem in go runtime because
I suspected the code to be quite similar. And I think go team fixed the
problem in ready() equivalent in go runtime, by adding a flag in Proc
equivalent so the proc (G in go) is put back to the run queue ...
Phil;
In go/src/pkg/runtime/proc.c:
>---------------------------------------------------------------------<
// Mark g ready to run. Sched is already locked. G might be running
// already and about to stop. The sched lock protects g->status from
// changing underfoot.
static void
readylocked(G *g)
{
if(g->m){
// Running on another machine.
// Ready it when it stops.
g->readyonstop = 1;
return;
}
...
>---------------------------------------------------------------------<
// Scheduler loop: find g to run, run it, repeat.
static void
scheduler(void)
{
lock(&sched);
...
if(gp->readyonstop){
gp->readyonstop = 0;
readylocked(gp);
}
...
