[haiku-development] Re: correct way to acquire_sem_etc()
- From: "François Revol" <revol@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 29 Oct 2008 23:23:33 +0100 CET
> Hi,
>
> could someone help me with an acquire_sem_etc() problem? I am unsure
> about
> the B_CAN_INTERRUPT flag and handling B_INTERRUPTED as the error
> code.
userland acquires are always interruptible.
Usually you don't want to be interruptible when you implement locking
primitives, to avoid screwing up the state.
> When exactly do I want acquire_sem_etc() to be interruptable, and who
> can
> interrupt me?
For things like read() hooks in drivers, when waiting for a buffer,
it's desirable to be interruptible, so someone can actually hit CTRL-C
in a terminal and get the desired behaviour.
In general I think anything that waits for an event with a long timeout
should be interruptible.
Anyone who can send unmasked signals to the current thread can
interrupt.
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...
> As for the specific problem I am trying to fix: In the usb_hid
> driver,
> Michael and I use a USB interrupt transfer callback semaphore. In
> other
> words, the thread that does ioctl() on the driver schedules an USB
> interrupt transfer, then it blocks on a semaphore which has been
> created
> like this:
Not really sure yet...
François.
Other related posts:
