l...@gnu.org (Ludovic Courtès) writes:
>> +(define (asyncs-still-working?)
>> + (let ((a #f))
>> +(system-async-mark (lambda ()
>> + (set! a #t)))
>> +(equal? '(a b c) '(a b c))
>> +a))
>
> I guess `equal?' is here to trigger an `SCM_TICK', right? Perhaps a
> comm
Hello!
Neil Jerram writes:
> Thanks! And here's the corresponding patch for master. It's slightly
> different, because scm_join_thread_timed in master allows for the join
> attempt timing out and should return a special timeout value in that
> case. Also I had to fix another problem, wait-con
l...@gnu.org (Ludovic Courtès) writes:
> Hello!
>
> Neil Jerram writes:
>
>> Here is a proposed patch for branch_release-1-8.
>
> At first sight this looks good to me.
Thanks! And here's the corresponding patch for master. It's slightly
different, because scm_join_thread_timed in master allows
Hello!
Neil Jerram writes:
> Here is a proposed patch for branch_release-1-8.
At first sight this looks good to me.
Thanks!
Ludo'.
Neil Jerram writes:
> "Julian Graham" writes:
>
>> Hi Neil,
>>
>>> Based on the synopsis above, I agree that moving step 1 inside the loop
>>> should fix this. In addition, though, I think it would be very good if we
>>> could add a minimal test that currently reproduces the deadlock, and so wi
"Julian Graham" writes:
> Hi Neil,
>
>> Based on the synopsis above, I agree that moving step 1 inside the loop
>> should fix this. In addition, though, I think it would be very good if we
>> could add a minimal test that currently reproduces the deadlock, and so will
>> serve to guard against f
2008/5/25 Julian Graham <[EMAIL PROTECTED]>:
> Hi everyone,
>
> While I was testing and debugging some of the SRFI-18 code that Neil
> and I were working on, I noticed a deadlock that happens in
> scm_join_thread_timed. I'm pretty sure it affects the 1.8 codebase as
> well, although it's probably
