platforms problems

[Reini Urban]

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/