platforms problems

Jonathan "Duke" Leto jonathan at leto.net
Thu Aug 9 01:52:35 UTC 2012


Howdy,

Ask and ye shall receive! https://github.com/parrot/parrot/issues/808

In general, I agree that the NCI tests are broken by design and they
need to be rethought and rewritten. It also seems that the threads
implementation needs some improvement (as pointed out by Reini) so
that the tests can be written less wrongly.

I am -1 to deprecating support for any platforms in relation to
merging the threads branch because these problems are related to the
speed of the machine running the tests and bugs in our threads, not
the platform involved.

Duke

On Wed, Aug 8, 2012 at 4:48 PM, Reini Urban <rurban at x-ray.at> wrote:
> On Thu, Aug 2, 2012 at 2:46 PM, Andy Dougherty <doughera at lafayette.edu> wrote:
>> On Thu, 2 Aug 2012, Andrew Whitworth wrote:
>>
>>> On Thu, Aug 2, 2012 at 6:56 AM, Jimmy Zhuo <jimmy.zhuo at gmail.com> wrote:
>>> > Hello,
>>> > I'd like to mark the failed tests to skip on those platforms temporally
>>> > since there is no developer resources to
>>> > work on those platforms.
>>>
>>> That's probably my preferred solution, for now. A failing test only
>>> matters if we can fix it, which we really don't have the developer
>>> resources to do right now. At least this way we can keep a record of
>>> what the problems are on which systems and hope we find somebody able
>>> to fix them later.
>>
>> Sometimes portability issues point out weaknesses in a platform.  Other
>> times, they expose weaknesses in parrot.  One of the biggest challenges is
>> identify which one you're dealing with.
>>
>> For the threads tests, it sure seems like a race condition to me that is
>> exposing a weakness in parrot's thread implementation.  Last time I
>> looked, the tests were relying on sleep() calls.  That seems wrong and
>> fragile to me.  No explicit sleep call should be needed.  The threading
>> interface ought to supply the necessary functions to ensure things are in
>> whatever state the tests are expecting.
>>
>> For the threads examples, I have no idea what they are actually supposed
>> to do -- there's no documentation -- so I was never sure what was supposed
>> to be happening with them, and couldn't usefully test them either.
>
> Why do we still have no GH ticket for this?
>
> I could reproduce the new threads deadlock in the nci test on all my
> slow machines.
> darwin/ppc, debian/mips, debian/sparc, and also linux with clang
> -faddress-sanitizer,
> which is about 2x slower than normal.
> t/pmc/task.t is also failing in the slow machines.
>
> I'm with Andy that sleep() is the real problem here.
> 1st the tests are way too fragile, and
> 2nd sleep() itself got more instable in the threads branch.
>
> Esp. this section loops in while. How can we ensure that the alarm signal
> is ever delivered, that the timer thread is not also waiting?
>
> thread.c-Parrot_thread_wait_for_notification(PARROT_INTERP)
> thread.c-{
> thread.c-    ASSERT_ARGS(Parrot_thread_wait_for_notification)
> thread.c-
> thread.c-#ifdef PARROT_HAS_THREADS
> thread.c:    LOCK(interp->sleep_mutex);
> thread.c-    while (interp->wake_up == 0)
> thread.c:        COND_WAIT(interp->sleep_cond, interp->sleep_mutex);
> thread.c-    interp->wake_up = 0;
> thread.c:    UNLOCK(interp->sleep_mutex);
> thread.c-#else
> thread.c-    Parrot_alarm_wait_for_next_alarm(interp);
> thread.c-#endif
> thread.c-}
>
>     2304 Thread_2503
>       2304 start
>         2304 main
>           2304 Parrot_api_run_bytecode
>             2304 Parrot_pf_execute_bytecode_program
>               2304 Parrot_cx_begin_execution
>                 2304 Parrot_cx_outer_runloop
>                   2304 Parrot_thread_wait_for_notification
>                     2304 _pthread_cond_wait
>                       2304 __semwait_signal
>                         2304 __semwait_signal
>     2304 Thread_2603
>       2304 _pthread_start
>         2304 Parrot_alarm_runloop
>           2304 _pthread_cond_wait
>             2304 __semwait_signal
>               2304 __semwait_signal
> --
> Reini Urban
> http://cpanel.net/   http://www.perl-compiler.org/
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev



-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC http://labs.leto.net
209.691.DUKE http://dukeleto.pl


More information about the parrot-dev mailing list