On Thu, 20 Mar 2003, Oliver Neukum wrote: > > were doing it, I'd not use the synchronous unlink call; > > "ought not" to matter, but we can be more sure than that. > > That's dangerous. We must have absolute confidence about whether > the message has gone over the wire or not. > Suppose it's a reset. We'd have a device at address zero without knowing > it. So this seems to be the easiest way.
Correct me if this is wrong, but it's not so easy to tell whether or not a message has gone over the wire. With UHCI, it would be necessary to unlink it and then wait for the start of the next frame to be certain. And even then, for bulk OUT messages you face the possibility that the message was received correctly by the device but the ACK handshake was lost, so the host doesn't _know_ that the message was received. In this case, it's very easy to use an asynchronous unlink rather than a synchronous one. All you have to do is wait for the struct completion again after the unlink call, with no timeout. Given that this whole matter revolves around updating the synchronous API interface, it's probably best not to use one synchronous call within the implementation of another. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
