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

> > 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.

Maybe, but I mean once I know it's been interrupted, I know it, I might
want to perform some ops regardless...

Anyway...
src/add-ons/kernel/file_systems/nfs/RPCPendingCalls.c:  while
(acquire_sem (calls->fSem)==B_INTERRUPTED);
src/add-ons/kernel/file_systems/nfs/RPCPendingCalls.c:  while
(release_sem (calls->fSem)==B_INTERRUPTED);

It's actually not on calls that are supposed to be interruptible.
Maybe it came from code that was supposed to be used in userland
first...

François.

Other related posts: