On 2008-10-30 at 00:45:47 [+0100], François Revol <revol@xxxxxxx> wrote: > > > Sometimes, even in locking primitives, it's done as > > > while (acquire_sem_etc(s, B_CAN_INTERRUPT, ...) == B_INTERRUPTED); > > > > > > This might be to eat signals and avoid delaying them instead, > > > though > > > I'm not sure. > > > I've seen that in the NFS addon code for ex. > > > It can't be to let the thread handle the signal, as it won't be > > > done > > > until it actually exit from the syscall... > > > > If that is done in kernel code, it's buggy. Signals are only handled > > right > > before leaving the kernel, that is this would become a busy loop. > > Do you mean it would always return B_INTERRUPTED while only 1 signal > arrived ?? Yep, until the signal is handled any interruptable call that would block, will return immediately with B_INTERRUPTED. > I always thought it would only happend on the call that actually cought > it. > And it'd look saner to me. > Actually, doesn't R5 work that way ? I don't know how BeOS works in this respect. I don't see how another behavior would make sense, though. Either you want a call to be interruptable -- then a pending interrupting condition (e.g. a signal) will interrupt it regardless of whether it interrupted another call before -- or you don't -- then nothing will interrupt it. I find this rather consequent: Signals can only be handled at a certain point, and the interrupting behavior gets the thread to this point as fast as the code it is currently executing allows it. CU, Ingo