> I'm not claiming anyone to be wrong. I want to solve > this problem.
i'm not sure there is a problem with notes. but i really can't answer that question. someone with a better understanding of what notes are supposed to be could answer this. > 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. i'm not convinced that you've explained why this change is correct or why it could solve the problem. after all, the NNOTED array is only 5 entries long. what if one gets 5 user notes before the system note? do you kill the process (isn't this how it works now?), make notes unreliable or block the sender? none of these options seems like an improvement to me. > > 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. i know. but sleep gives other processes a large window to deliver more notes. what is the external note, by the way? a keyboard interrupt? > Being curious, why is sleep() in a note handler a bad > idea? as i see it (please chime in if you disagree), a process in a note handler is in a funny state. the kernel treats this state as funny as it keeps up->notified around to note (ha!) this fact. as a general rule, i would think that anything prolonging this funny state would tend to cause problems. > Dont tell me... But i cant think of any other way to catch > linux syscalls for now. without changing your mechanism, you could move the work out of the note handler and let the note handler just set state. for example, byron's rc ^c handler just set a global interrupted variable. there were only three or four places where this variable was checked. these locations were carefully vetted for longjmp safety. and lonjmp'ed back to the command loop (if interactive). it doesn't sound like it would work well, but it worked perfectly. about the same time byron was working on rc, i wrote my own shell. i wasn't convinced that byron's technique would work or would be more reliable than doing things from the signal handler. ... experience says that i was wrong. there's also a special dodge of a note continuation handler for ape available. this hints that the note interface might be pushed too far by ape. - erik
