Hi all,
I just noticed that the fix for #1564 would introduce a fresh bug.
Stupid me has sent out a version where the debug code was commented out.
A patch will take several days to come around, sorry.
The issue is in scheduler.scm ##sys#thread-basic-unblock!
It used to begin
(define (##sys#thread-basic-unblock! t)
(dbg "unblocking: " t)
(##sys#setislot ct 11 #f)
me changed that to
(define (##sys#thread-basic-unblock! t)
(dbg "unblocking: " t)
#;(if (##sys#slot t 11) ;; remove this case after testing
(##sys#error '##sys#thread-basic-unblock! "Internal scheduler error:
unclean unblock"
(##sys#slot t 11)))
The idea of the change was to collect all changes to slot #11 of a thread
at a single spot. Namely, ##sys#thread-clear-blocking-state! . This time
the removals only.
Doing so would have the advantage that we could export the procedure from
the scheduler for eggs to overwrite it with versions aware of custom
blocking objects.
Though when I went over the consequence of the fix - the removal of the now
possibly obsolete code in srfi-18, I learned that I should have left the
comment out, then it would have caught the issue. The proposed fix is to
keep both for now:
(define (##sys#thread-basic-unblock! t)
(dbg "unblocking: " t)
(##sys#setislot ct 11 #f) ;; required by condition-variable-*!
(if (##sys#slot t 11) ;; remove this case after testing
(##sys#error '##sys#thread-basic-unblock! "Internal scheduler error:
unclean unblock"
(##sys#slot t 11)))
Later we should decide how to handle slot #11.
Either (for performance) manage the blocking queue inline in srfi-18 and
clean slot #11 there inline too.
Alternatively change condition-variable-*! to use ##sys#thread-unblock! -
which would unqueue the thread and clean slot #11 - and use a version of
##sys#thread-basic-unblock! which expects slot #11 to be cleaned already.
Cheers
/Jörg
_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
