> No! Notes are bufferd in the up->note[] array. If you are in the note handler,
> another process *can* send you further (NUser) notes without doing any harm.
>
> If we are in the note handler (up->notified == 1) and notify() gets hit,
> it will do nothing and return 0 see:
>
> /sys/src/9/pc/trap.c: notify()
> ...
> if(n->flag!=NUser && (up->notified || up->notify==0)){
> if(n->flag == NDebug)
> pprint("suicide: %s\n", n->msg);
> qunlock(&up->debug);
> pexit(n->msg, n->flag!=NDebug);
> }
>
> if(up->notified){
> qunlock(&up->debug);
> splhi();
> return 0;
> }
> ...
>
> The problem is when we get a NDebug note *after* an NUser note. Then
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. including explaining why it's okay
to not terminate a process which has not handed a system
note when it gets another.
the example program is carefully constructed to abuse
notes beyond reason. sleeping in a note handler seems
like it's pushing the limits to me. 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. 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.
- erik
