Am Donnerstag, 29. April 2004 20:07 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>1. Does waiting for the completion handler actually change the
> >>> semantics? I would think not, but I am not sure.
> >>
> >>You mean, does it change the existing semantics of synchronous
> >>usb_unlink_urb()? Yes, it does. Currently usb_unlink_urb() guarantees
> >>that when it returns the completion handler will have finished _only_ if
> >>it returns with no error. If it returns with an error code then the
> >>completion handler might not even have started running yet.
> >
> > But we don't violate existing behavior, do we?
> > Always returning only after the completion handler has run seems
> > to be legal to me.
>
> And it does return after the completion handler runs -- iff the
> unlink succeeded, and it was a synchronous unlink.
>
>
> Making it wait even if the URB was completing normally would indeed
> change the semantics ... remember the routine is all about UNLINKING.
> Which is why using it to achieve anything else is bogus.
Why, if nobody wants to just unlink synchronously?
Is there a requirement that usb_unlink_urb() block only if there's no error?
Or, in other words, is software that is broken if it always waits?
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
