"Julian Graham" <[email protected]> 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 future regressions here. Do you have such a test?
>
> I don't -- it seems to be pretty dependent on timing. I noticed it
> while running my SRFI-18 test suite in a loop, and it took hours to
> trigger. Any suggestions?
I'm looking into this now. Here's a nice little program that
reproduces the deadlock.
(use-modules (ice-9 threads))
(define other-thread
(make-thread sleep 5))
(letrec ((delay-count 10)
(aproc (lambda ()
(display delay-count) (newline)
(set! delay-count (- delay-count 1))
(if (zero? delay-count)
(begin
(display "sleeping...\n")
(sleep 10)
(display "waking...\n"))
(system-async-mark aproc)))))
(sleep 2)
(system-async-mark aproc)
(join-thread other-thread))
Regards,
Neil
