Oliver Neukum wrote:
Like this version better?
No, it still has that "arbitrary timeout" pessimization. The only difference is a bigger timeout.
If progress in the typical case is clearly forward, the call will very likely succeed. But that doesn't mean that the atypical case where no progress is made can be ignored. An infinite loop is never acceptable.
That's because they don't make efficient use of BogoMIPS; the time is better spent cracking ciphers. But this isn't such a loop. If anyone ever sees a problem with the current "retry till success" logic (look at what a spinlock does, or various other schemes to allocate resources) in real world situations, then it'd be time to look again. Lacking such input, morphing code that probably succeeds into code that certainly fails can never improve robustness. I'd sure rather see systems that progress under extreme load than ones that give up a few seconds into such loads, as you're advocating.
Could you live with returning the number of bytes that remain to be transfered so that higher layers can recover from this condition?
Not unless there's a real error. In that case, the code already returns that byte count ... as accurately as the lower level code provides it. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
