[haiku-development] Re: correct way to acquire_sem_etc()

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 30 Oct 2008 01:56:39 +0100

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

Other related posts: