Re: [9fans] 9front sleep interrupted in kproc?

[cinap_lenrek@felloff.net]

its just a case of defensive programming paranoia. i did the change
after sl reported wifi kproc exiting (went into Broken) state. there
seemed no other explaination other than a note interrupting it
so i made all the kprocs safe to be interrupted by notes. i found this
pattern in many places. most of the kprocs are just loops waiting for
something and in case of error, just restart the loop. even if it is
obvious that nobody is calling error() in there. (see devfloppy
kproc for example). you just setup the error label at before your loop
and it make it automatically restart your loop on errors. this doesnt
cost you any cycles in the loop. when i see this code, i can stop worrying
and assume *less* about of the surroundings.

so simply put, yes, you are right. these kprocs shouldnt get interrupted.
but i made sure to catch the case anyway.

i wouldnt rule out notes out of the blue. the use of postnote() is racy in
many places. a Proc* pointer is not a good identifier for a process
*unless* you can guaratee that the proc will not exit while you call
postnote(). alarms have this race. pexit() just does up->alarm = 0;
to clear alarms. if the alarm kproc was already commited
posting you the note at this point (and before it got hold onto
the p->debug qlock), the new process reusing your Proc*
structure can get the alarm out of the blue.

--
cinap