From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 5792 invoked from network); 21 Dec 2020 13:11:48 -0000
Received: from ewsd.inri.net (107.191.116.128)
  by inbox.vuxu.org with ESMTPUTF8; 21 Dec 2020 13:11:48 -0000
Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Mon Dec 21 08:09:00 -0500 2020
Message-ID: <7C972FA346E83CE34B2349FC63E619E9@felloff.net>
Date: Mon, 21 Dec 2020 14:08:38 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <X+AlUdO6wFrgcC/c@alice>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: extended social event-based NoSQL-oriented DOM base 
Subject: Re: [9front] modification to sleep in changeset 285df38d5ed3
Reply-To: 9front@9front.org
Precedence: bulk

> Is it safe to call procsave after unlocking
> the process and the rendezvous in sleep?

yeah, i dont see any problem. the only thing that
holding Proc.rlock prevents is that someone doing
a wakeup() of the process, which basically does
a ready() on it, putting it back on the run queue.

procsave() itself doesnt change the process
state and doesnt block/sleep itself.

having the process on the run queue while it
executes procsave() shouldnt be an issue.
the scheduler cannot dequeue it until the
process has set up->mp = nil, which happens
after procsave() in schedinit() when the
scheduler stacks have been switched.

also note that procsave is also executed without
any locks when we call sched(). which is called
for example when a qlock() goes to sleep.

theres nothing there preventing the process
that is commited to sleep to be immediately
re-awakend by someone else as soon as qlock
releases the Qlock.use spinlock.

--
cinap