> 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
