Hi
On Sat, Sep 26, 2015 at 7:56 PM, Krzysztof Kotlenga wrote:
> David Herrmann wrote:
>
>> Krzysztof Kotlenga wrote:
>>> Krzysztof Kotlenga wrote:
>>>
2. Maybe I don't get something right - please enlighten me if
that's the case - but prioq_put or rather shuffle_up
David Herrmann wrote:
> Krzysztof Kotlenga wrote:
>> David Herrmann wrote:
>>> Krzysztof Kotlenga wrote:
>>
>> Some more or less minor points still stand though:
>>
>> - errored/disabled bus-inputs are never freed, even after client
>> disconnect (!)
>
> What's a "bus-input"?
Hey
On Thu, Sep 24, 2015 at 1:15 AM, Krzysztof Kotlenga wrote:
> Krzysztof Kotlenga wrote:
>
>> 2. Maybe I don't get something right - please enlighten me if that's
>> the case - but prioq_put or rather shuffle_up function is buggy.
>>
>> (...)
>>
>> Am I wrong to believe
David Herrmann wrote:
> Krzysztof Kotlenga wrote:
>> Krzysztof Kotlenga wrote:
>>
>>> 2. Maybe I don't get something right - please enlighten me if
>>> that's the case - but prioq_put or rather shuffle_up function is
>>> buggy.
>>>
>>> (...)
>>>
>>> Am I wrong to believe that it should have
Krzysztof Kotlenga wrote:
> I recommend the following gdb script, because it provides some
> possibly interesting output:
Slightly fixed version:
https://gist.github.com/pocek/709d8c098d632ed1f21e
The first one was incorrectly printing pending_iteration instead of
prepare_iteration field.
Krzysztof Kotlenga wrote:
> Two things:
> (...)
One more. Prioq compare functions in sd-event.c contain this:
/* Stability for the rest */
if (x < y)
return -1;
if (x > y)
return 1;
How comparing prioq_item.data pointers is going to ensure stability?
Shouldn't it be:
if
Krzysztof Kotlenga wrote:
> 2. Maybe I don't get something right - please enlighten me if that's
> the case - but prioq_put or rather shuffle_up function is buggy.
>
> (...)
>
> Am I wrong to believe that it should have swapped 2 and 1, not 2 and
> 0?
OK, I've finally realised that I'm a
Hi.
There were many reports of "Looping too fast. Throttling execution a
little" behavior but they never got anywhere. Not this time. At least
for this particular case.
Initially I was able to reproduce this issue just by calling `systemctl
restart some_specific_service` - then most of further