From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8bfcd212b26e5609a601c22822c1626a@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Sun, 13 Jun 2010 23:34:18 +0100
To: 9fans@9fans.net
In-Reply-To: <125aa93ce1c20a7853557a368e77b0ca@kw.quanstro.net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-nhpwspqxyiwustrjnexzymkovl"
Subject: Re: [9fans] 9vx, kproc and *double sleep*
Topicbox-Message-UUID: 32e1ec84-ead6-11e9-9d60-3106f5b1d025

This is a multi-part message in MIME format.
--upas-nhpwspqxyiwustrjnexzymkovl
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

i wasn't clear enough what i meant by `interrupt handler'. i didn't mean
the device-specific function, but its caller. in pc/trap.c you see
			if(up && !clockintr)
				preempted();
and on other platforms (perhaps not enough) there are calls to preempted()
in the interrupt handler(s) that despatch the device-specific ones.
preempted calls sched, which can switch to another process before returning.
--upas-nhpwspqxyiwustrjnexzymkovl
Content-Type: message/rfc822
Content-Disposition: inline

Received: from gouda.swtch.com ([67.207.142.3]) by lavoro; Sun Jun 13 14:45:41 BST 2010
Received: from localhost ([127.0.0.1] helo=gouda.swtch.com)
	by gouda.swtch.com with esmtp (Exim 4.69)
	(envelope-from <9fans-bounces@9fans.net>)
	id 1ONnPx-0007GF-2l; Sun, 13 Jun 2010 13:40:05 +0000
Received: from ladd.quanstro.net ([69.55.170.73])
	by gouda.swtch.com with esmtp (Exim 4.69)
	(envelope-from <quanstro@quanstro.net>) id 1ONnPu-0007GA-0L
	for 9fans@9fans.net; Sun, 13 Jun 2010 13:40:02 +0000
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 13 Jun 2010 09:32:38 -0400
To: 9fans@9fans.net
Message-ID: <125aa93ce1c20a7853557a368e77b0ca@kw.quanstro.net>
In-Reply-To: <64a6fa23d8a01d86312954ab451692d0@terzarima.net>
References: <64a6fa23d8a01d86312954ab451692d0@terzarima.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 9vx, kproc and *double sleep*
X-BeenThere: 9fans@9fans.net
X-Mailman-Version: 2.1.10
Precedence: list
Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net>
List-Unsubscribe: <http://mail.9fans.net/options/9fans>,
	<mailto:9fans-request@9fans.net?subject=unsubscribe>
List-Archive: <http://mail.9fans.net/private/9fans>
List-Post: <mailto:9fans@9fans.net>
List-Help: <mailto:9fans-request@9fans.net?subject=help>
List-Subscribe: <http://mail.9fans.net/listinfo/9fans>,
	<mailto:9fans-request@9fans.net?subject=subscribe>
Sender: 9fans-bounces@9fans.net
Errors-To: 9fans-bounces+forsyth=terzarima.net@9fans.net

> that's only because the clock interrupt handler directly or indirectly (eg,
> via sched) calls spllo, and other trap or interrupt handlers could do that.

wouldn't that be fatal with shared 8259 interrupts?

- erik
--upas-nhpwspqxyiwustrjnexzymkovl--