On 2012.07.10 16:31, Peter Stuge wrote: > It makes sense from the point of view of critical sections, but > starting the timer before the transfer has actually been submitted > would mean that the timeout while the transfer is on the bus will > always be shorter than the user-specified timeout, offset by however > long it takes to do the submit itself
Don't we issue a calculate_timeout() call first thing in libusb_submit_transfer() though? My understanding is that, whether we start the timeout before or after the transfer, the actual point at which the timeout expires won't change since it's calculated first thing in the transfer call, as it should, so I fail to see any added offset either way. Especially it seems logical to want any software overhead to be part of our timeout. Otherwise, trying to determine when a timeout will actually expire will require some guesswork for our users. As such, we might as well have the timeout initiated as soon as we get the lock, in add_to_flying_list(), regardless of whether a transfer has had a chance to be set or not. This change may actually be helpful if, for instance a user sets an unrealistically small transfer timeout with regards to their system capabilities (because of system load, etc.), which results in the timeout expiring before libusb(x) gets a chance to speak to the bus. By arming the timerfd early, we may make it more explicit for such an user to realize that they have to take into account libusb(x)'s overhead... Thus, unless I'm misreading what you meant here, I don't currently see an issue with Hans' suggestion, and that's what I would vote for too. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
