>> 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
