[haiku-development] Re: correct way to acquire_sem_etc()
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 30 Oct 2008 13:21:11 +0100
On 2008-10-30 at 02:59:39 [+0100], François Revol <revol@xxxxxxx> wrote:
> > > 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...
Which you can do leaving out the B_CAN_INTERRUPTED flag. :-)
> 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...
Yep, probably. It's not that problematic, though, since acquire_sem() is
not interruptable anyway.
CU, Ingo
Other related posts:
