From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4C1351E6.8050109@bouyapop.org>
Date: Sat, 12 Jun 2010 11:22:46 +0200
From: Philippe Anel <xigh@bouyapop.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100318)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <4C1242CD.5020202@bouyapop.org>	<AANLkTilQUS_JD8CWkcSJt_boJ1tBTG4i_xjZTfYfeyUl@mail.gmail.com>	<f398e344c84e5946e0189ebb69638d57@kw.quanstro.net>
	<4C13311B.4050704@bouyapop.org>
In-Reply-To: <4C13311B.4050704@bouyapop.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 9vx, kproc and *double sleep*
Topicbox-Message-UUID: 31cd7714-ead6-11e9-9d60-3106f5b1d025


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);
        }
    ...