> i think you may be misunderstanding what i'm saying.
> the test for n->flag does not appear to be accidental.
> i am not quite sure why that test is there, but i go on
> the assumption that presotto knew what he was doing.
> if you're going to claim he was wrong, i think you'd better
> have good reasons.
I'm not claiming anyone to be wrong. I want to solve
this problem.
> including explaining why it's okay
> to not terminate a process which has not handed a system
> note when it gets another.
which has not handled what? All it checks is if here is *any* note
handled currently. And if the *next* note to be handled is
a system note.
If here are any other implications in the check i dont see
here please tell.
I also noted that i think this is the correct behavior in
the previous mail. My patch is on the other side inpostnote(),
where the note is put in the up->note[] array, not where
it decides to kill the proc.
> the example program is carefully constructed to abuse
> notes beyond reason.
Its the extract of what linuxemu needs to do. Its not just
constructed to annoy anyone or prove someone wrong.
> sleeping in a note handler seems
> like it's pushing the limits to me.
It doesnt matter if we sleep() here. You could do a
write() or any other syscall instead. Or do the looping
and wait for the timer interrupt.
Being curious, why is sleep() in a note handler a bad
idea?
> having two threads
> sending notes to the same proc including one generating
> a constent stream of gpf's seems like it's a bit beyond what
> notes were intended for. if you remove the sleep from the
> note handler, all the notes are handled.
Not the case for me... enabling the for loops results in the
same crash here. (It takes a little bit longer than doing the
sleep() thing, maybe you need to increase loop count to
trigger it on a faster machine)
> i don't think by itself
> it's particularly compelling example. your vm example
> may be compelling. i don't understand it yet, though.
> so i can't say.
> i'm not arguing for broken system calls. but notes, like
> signals, tend to be convienent but fraught interfaces.
> maybe now that plan 9 has given in to multithreading,
> it's time to replace notes.
Dont tell me... But i cant think of any other way to catch
linux syscalls for now.
> - erik
--
cinap
