On Thu, Nov 06, 2008 at 09:18:47PM -0800, Roman Shaposhnik wrote: > On Nov 5, 2008, at 9:40 PM, Nathaniel W Filardo wrote: >> Would this suffice? > > It sounds like exactly the kind of thing I was talking about.
OK. To reiterate what I said earlier, these kinds of "soonstop"-ed processes may still make some amount of progress in the kernel before becoming stopped, but they will indeed stop at their next scheduling opportunity, and ideally well before (when they go to return to userland). One could imagine a parallel "soonnote" which considered the note delivered even if the process was asleep in I/O. This might be the more appropriate thing for sending kill requests from the shell? Having not looked at the shell, this might be a bad idea; I'm not sure. >> Did I miss something obvious? > > And this would be a million dollar question here. I don't > think you did (although Eric constantly warns us of > dragons), but on the other hand I have very little > experience with the kernel itself. I hope somebody comments on the fencing that is or isn't needed here. Since we have parts of the kernel peeking witout locks at ->procctl, I worry about races, and wonder how, or if, the current design avoids them. ( Incidentally, if you're curious about in-kernel development and want to look at a strange system, it is exactly the species of dragons we have encountered here -- where the kernel has hijacked a userland thread to do driver operations, and is potentially sleeping with driver resources held or in local store -- that drove the design of the Coyotos kernel to being a strictly transactional system. AFAIR there it is always possible to tell a thread to kill itself after its current transaction or, if asleep or in commit phase, to force it out of stall queues and then kill it. ) --nwf;
pgp81iSoj5Hin.pgp
Description: PGP signature
