From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 6 Nov 2008 21:48:34 -0800 From: Roman Shaposhnik In-reply-to: <77d79e8bbb30c217627e28f5ad335e83@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <7EC4CEFD-DEEE-40CF-BF74-1170EDAD7229@sun.com> MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <77d79e8bbb30c217627e28f5ad335e83@quanstro.net> Subject: Re: [9fans] Quick question on stopping a process that waits for IO Topicbox-Message-UUID: 33e62f66-ead4-11e9-9d60-3106f5b1d025 On Nov 5, 2008, at 4:55 AM, erik quanstrom wrote: >>>> I'm asking is -- "dear kernel, please don't advance this process >>>> even >>>> if you otherwise can". All I need is a frozen state so that I can >>> >>> not so easy on a multiprocessor. (unless you turn all but one >>> processor off.) >> >> Hm. May be its getting late, but I can't quite see why that would >> be the case (or may be I didn't quite communicate the intent >> in my plea to the kernel ;-)) >> >> The target process is *already* waiting for the IO stuck inside the >> kernel. It is not on a runqueue, not it is considered to be places >> there. > > since procwrite doesn't acquire anything other than the debug lock, > how do you know? the proc could start up again before you notice. How? If there's a stop message already written to /proc/n/ctl. Once that is done, the process is guaranteed to be in 2 states and those states only: continue waiting for the I/O, being actually Stopped. Both of the don't let the scheduler take it to the runqueue. > the place to catch processes is on syscall entry and/or exit. stop > messages are only checked on syscall entry. > > i have a feeling that you want something other than notes for > your problem. If by the problem you mean stopping a process doing I/O than, I would gladly accept any solution be it notes or otherwise. > cpu arranges that del works. Well, it doesn't on Stopped processes. Thanks, Roman.