Am Montag, 13. Januar 2003 17:37 schrieb Alan Stern:
> On Mon, 13 Jan 2003, Oliver Neukum wrote:
> > > As far as guaranteeing that when usb_unlink_urb() returns from a
> > > synchronous unlink, the completion handler will have already finished
> > > -- so far as I can tell there is currently no such guarantee. At
> > > least, the
> >
> > There's if the unlink doesn't return an error.
> >
> > > kerneldoc preceding usb_unlink_urb() is sufficiently vague that it
> > > doesn't make this promise. Of course, we need to have something like
> > > this. But in principle there should be no problem -- or rather, the
> > > only problem is
> >
> > Not trivial. The only way to do it is to use complete_and_exit() in the
> > completion handler.
>
> I disagree. How about having the core code that calls the completion
> handler manage the necessary synchronization? Of course, this would have
> to be coordinated with usb_submit_urb() and usb_unlink_urb().
Yes, this is the other option. I tried to implement that.
Did you have a look at the patch ?
> > > dealing with the case that the handler resubmits. What happens if the
> > > handler resubmits the URB, and another thread tries to unlink the
> > > newly-submitted incarnation before the handler has returned?
> >
> > We must make sure that an interrupt handler is not reentered.
>
> So some type of synchronization of this sort is necessary in any case.
Well, it's a hard problem. We might need a counter or something similar.
It's a difficult problem I hadn't thought of.
Regards
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
