green_threads

[Matthew Boyle]

On 20/10/11 18:46, Stefan Seifert wrote:
> On Thursday 20 October 2011 18:14:31 Matthew Boyle wrote:
>> On 19/10/11 17:33, Matthew Boyle wrote:
>>> it currently fails to build on Linux (Fedora 14, x64) when configured
>>
>>> using { --cc=g++ --ld=g++ --link=g++ }:
>> I'm also seeing intermittent failures in<t/pmc/alarm.t>.  usually just
>> tests 3 and 4, occasionally 1 and 2, but i've seen the first four tests
>> all fail at once.
>>
>> i've been able to consistently reproduce it thus:
>>
>> COUNT=1; while prove t/pmc/alarm.t; do echo $((COUNT++)); done;
>>
>> the failure seems to be extremely load-dependent (kicking off a couple
>> of { cat /dev/zero | sha384sum } pipelines in the background can make it
>> fail within a couple of iterations).
>
> Thank you. That's an excellent test procedure.
> I can reproduce it and it's pretty obvious, that the test itself is in error.

no problem!  glad you found it useful.

i've not seen the problem since, so i think this can safely be 
considered fixed :-)

> The test assumes that the alarms will fire in the order in which they are set
> and that they execute in the same order. But on a highly loaded system and
> with active preemption it's no longer possible to tell which task will run in
> which order. So the only meaningful tests are the "All alarms executed",
> "Alarms actually waited" and "Alarm/sleep interaction" tests.
>
> And even of these these, the "Alarms actually waited" test could wrongly
> succeed and the "Alarm/sleep interaction" wrongly fail on an extremely loaded
> system. But those are probably inherent with timer related tests.

yeah.  fun things to test, aren't they? :-/

cheers,

--matt


-- 
Matthew Boyle, Systems Administrator, CoreFiling Limited
Telephone: +44-1865-203192  Website: http://www.corefiling.com