On 2012.08.04 10:19, Hans de Goede wrote:
> Correction, you forgot to add the arm_timerfd_for_next_timeout() call we
> agreed would be added to the transfer submission failure path
Forgot about that one - Thanks for spotting it. I have now modified the
patch to include this change and pushed it t
Hi,
On 08/04/2012 10:59 AM, Hans de Goede wrote:
> Note I did find one more issue wrt to timer handling, but that is unrelated
> (and in another part of the code), so lets just push this patch and then fix
> that issue with a separate patch. See my next mail on that.
Scrap that, upon typing a det
Hi,
On 08/04/2012 10:59 AM, Hans de Goede wrote:
> Hi,
>
> On 08/03/2012 02:46 PM, Pete Batard wrote:
>> Attached is my final proposal then.
>>
>
> Looks good, ack.
>
Correction, you forgot to add the arm_timerfd_for_next_timeout() call we
agreed would be added to the transfer submission failure
Hi,
On 08/03/2012 02:46 PM, Pete Batard wrote:
> Attached is my final proposal then.
>
Looks good, ack.
Note I did find one more issue wrt to timer handling, but that is unrelated
(and in another part of the code), so lets just push this patch and then fix
that issue with a separate patch. See m
Attached is my final proposal then.
On 2012.08.03 10:13, Hans de Goede wrote:
That works for me, I agree the original code is hard to read, maybe move
the refactoring to a separate patch though ?
Well, I don't really see it as refactoring, as we're moving a section of
code that used first int
Hi,
On 08/02/2012 01:28 AM, Pete Batard wrote:
> On 2012.08.01 12:52, Hans de Goede wrote:
>> Hmm, I hadn't noticed the explicit disarm there, since the
>> handle_timeouts_locked code just cancels
>> transfers and does not do anything io-intensive, the run-time for
>> handle_timeouts_locked will b
On 2012.08.01 12:52, Hans de Goede wrote:
> Hmm, I hadn't noticed the explicit disarm there, since the
> handle_timeouts_locked code just cancels
> transfers and does not do anything io-intensive, the run-time for
> handle_timeouts_locked will be
> short, so I see no value in the disarm there, and
Hi,
On 07/22/2012 01:27 PM, Pete Batard wrote:
> On 2012.07.13 01:27, Pete Batard wrote:
>> What will happen then is I'll submit a proposal to this list with all
>> the enhancements we talked about sometime next week
>
> Here we go.
>
> I'm still not entirely sure disarming the timerfd in handle_t
On 2012.07.13 01:27, Pete Batard wrote:
What will happen then is I'll submit a proposal to this list with all
the enhancements we talked about sometime next week
Here we go.
I'm still not entirely sure disarming the timerfd in
handle_timerfd_trigger() is that beneficial, but either way, it
s
On 2012.07.13 01:27, Pete Batard wrote:
> Same here. And my concern is that the disarm we do in
> handle_timerfd_trigger() isn't
"currently protected with a lock, but that's fairly easy to address." is
what I meant to add there.
/Pete
On 2012.07.12 22:00, Hans de Goede wrote:
> I believe that all arms / disarm should be done under the
> flying transfer lock.
Same here. And my concern is that the disarm we do in
handle_timerfd_trigger() isn't.
> Rather then reasoning ourselves a headache about how
> it is absolutely safe in al
Hi,
On 07/12/2012 01:19 AM, Pete Batard wrote:
> On 2012.07.11 10:18, Hans de Goede wrote:
>> Ok, with this patch added I think the end-result is better then
>> Pete's patch + my suggest change to only do the disarm based
>> on a flag.
>>
>> So Pete, if you agree lets go with Peter's 2 patches.
>
On 2012.07.11 10:18, Hans de Goede wrote:
> Ok, with this patch added I think the end-result is better then
> Pete's patch + my suggest change to only do the disarm based
> on a flag.
>
> So Pete, if you agree lets go with Peter's 2 patches.
Still on the fence on that one. I'd like to have the sec
Hi,
On 07/10/2012 05:31 PM, Peter Stuge wrote:
> Hey,
>
> Hans de Goede wrote:
>> doing the disarm without the flying-transfers lock held is racy, ie:
>
> Bringing back the old behavior was a start. Yes, race also. The
> attached patch on top of the previous fix avoids the race, and is
> available
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, off
Hey,
Hans de Goede wrote:
> doing the disarm without the flying-transfers lock held is racy, ie:
Bringing back the old behavior was a start. Yes, race also. The
attached patch on top of the previous fix avoids the race, and is
available also via
git fetch git://git.libusb.org/libusb-stuge.git fo
Hi,
On 07/10/2012 02:40 PM, Peter Stuge wrote:
> Hans de Goede wrote:
>> I had looking further into this / writing a patch on my todo list,
>> looks like you beat me to it, thanks for working on this!
>>
>> You're patch looks good, one possible optimization would be to
>> give arm_timerfd_for_next
Hans de Goede wrote:
> I had looking further into this / writing a patch on my todo list,
> looks like you beat me to it, thanks for working on this!
>
> You're patch looks good, one possible optimization would be to
> give arm_timerfd_for_next_timeout() an extra "int stop_timer"
> argument and on
On 2012.07.10 12:18, Hans de Goede wrote:
> one possible optimization would be to
> give arm_timerfd_for_next_timeout() an extra "int stop_timer"
> argument and only call disarm_timerfd() when that argument is true.
I like that idea. I'll get on to it and submit a v2 when I get a chance.
Regards,
Hi,
On 07/10/2012 01:01 PM, Pete Batard wrote:
> I expect the attached patch to fix the likely bug reported by Hans.
>
> As previously indicated, we should be able to either rearm the next timer or
> disarm all timers in the arm_timerfd_for_next_timeout() call of io.c,
> especially as we always
20 matches
Mail list logo
