Re: [9fans] Quick question on stopping a process that waits for IO

[erik quanstrom <quanstro@quanstro.net>]

>> Is there any way I can poke the target process so that it gets attention
>> from the scheduler an can be put in a Stopped state?
>
> I know, I know we all don't like those guys who talk to themselves
> on mailing lists replying to their own emails, but since there were
> no takers here's what I cooked up so far:
>    echo stop > /proc/n/ctl &
>    echo ping > /proc/n/note
>    cat /proc/n/note > /dev/null
>
> That of course doesn't quite work either since once I resume 'n'
> by issuing
>     echo start > /proc/n/ctl
> the process fails with:
>     error reading <stdin>: interrupted

this is an uncaught error in port/proc.c:/^sleep.  many interruptable
calls to sleep are wrapped by
	while(waserror())
		;
	sleep(...);
	poperror();

but this is a catch-22.  if the i/o resumed and didn't send a note,
it would not be possible to interrupt processes with del with rio's
current convention.

on the other hand, sending a note is the only way to get to procctl
unless one is doing syscall tracing.

oddly procctl says
/*
 *  called splhi() by notify().  See comment in notify for the
 *  reasoning.
 */
but there doesn't seem to be a comment in any version of notify
i can find.

>
> So the question remains -- what is the proper way of putting a process
> that waits for an IO into a Stopped state?

i don't think it's possible without changing the kernel.
but it's a good question, why does it work this way?
obviously one doesn't want to stop a process and kernel work in
the middle of i/o.  there may be locks involved, etc.
but one could easily check for Proc_stopme on syscall
exit.

does anyone remember the thinking that went into this?

- erik