Hey Robert, I've found the issue and it is related to unwind-protect changes. Symbol is exported from both packages, but it is the same symbol. Problem doesn't manifest itself in this merge request[1]. Hopefully running ECL from this unmerged branch solves your problem too. Thank you for your persistance and investigation.
Best regards, Daniel [1] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/119 W dniu wto, 04.09.2018 o godzinie 20∶08 +0200, użytkownik Robert Larice napisał: > Hello Daniel, > > if I grep for interrupts-enabled I see both > si::*interrupts-enabled* > and > ext::*interrupts-enabled* > and there is at least one or two commits which did > rename such things. perhaps there is some confusion. > > with my debian dished SLIME I've both NIL, > si::*interrupts-enabled* > NIL > ext::*interrupts-enabled* > NIL > > Best Regards, > Robert > > Daniel Kochmański <dan...@turtleware.eu> writes: > > > Hey Robert, > > > > nice analysis. While I have the newest ECL and the newest bordeaux- > > threads I've tried the snippet in SLIME REPL. > > > > CL-USER> si:*interrupts-enabled* > > T > > > > But when I run this snippet from console I have: > > > > > si:*interrupts-enabled* > > > > NIL > > > > Moreover: > > > > > (bt:make-thread (lambda () (print `(jd ,si:*interrupts- > > > enabled*)))) > > > > (JD T) > > > > So it is a bug in ECL - interrupts are disabled indeed in the main > > thread by default. I'm looking into it at this very moment. Thank > > you > > for investigating. When fix is merged into develop branch I'll > > notify > > you. > > > > Best regards, > > Daniel > > > > > > W dniu pon, 03.09.2018 o godzinie 22∶31 +0200, użytkownik Robert > > Larice > > napisał: > > > Hello Daniel, > > > > > > I continued to search for the culprit. > > > First I tried a second machine, > > > which showed exactly the same problem. > > > Thus I think you might not have used the > > > same bordeaux thread version, I have > > > bordeaux-threads-v0.8.6 > > > > > > The minimised snippet can be further minimised to this: > > > (ql:quickload :bordeaux-threads) > > > (let ((lock (bordeaux-threads:make-lock)) > > > (cvar (bordeaux-threads:make-condition-variable))) > > > (bordeaux-threads:with-lock-held (lock) > > > (handler-case (bordeaux-threads:with-timeout (0.001) > > > (mp:condition-variable-wait cvar lock)) > > > (bordeaux-threads:timeout () nil)))) > > > and still showes the same "hang" > > > > > > Then I started to macroexpand the stuff, and saw the > > > with-timeout depends on interrupting a thread > > > to terminate it after timeout. > > > Merely guessing, I tried to wrap the whole code into a > > > (mp:with-interrupts > > > ... ) > > > and voila, the piece starts to work properly. > > > But actually, if I've glimpsed the doc correctly, > > > the interrupts should have been enabled by default. > > > > > > Thus it seems either the bordeaux threads library is missing > > > a with-interrupts, or there is a bug in ecl > > > which doesn't enable these interrupts per default. > > > > > > Best Regards, > > > Robert > > > > > > > > > Daniel Kochmański <dan...@turtleware.eu> writes: > > > > > > > Hey Robert, > > > > > > > > I can't reproduce the problem with the newest ECL code (from > > > > git > > > > develop branch) on my host. lparallel works fine and this > > > > snippet > > > > does > > > > terminate after timeout. > > > > > > > > CL-USER> (ext:lisp-implementation-vcs-id) > > > > "ba6e6ddde780c097918673f16c7aba05f354d022" > > > > > > > > Best regards, > > > > Daniel > > > > > > > > W dniu nie, 02.09.2018 o godzinie 12∶27 +0200, użytkownik > > > > Robert > > > > Larice > > > > napisał: > > > > > I tried to understand where the issue is located. > > > > > > > > > > In :lparallel file lparallel-20160825-git/src/thread- > > > > > util.lisp > > > > > there is a stanza which tries to check for the implementation > > > > > of the :timeout capability > > > > > > > > > > > ;;; Check for timeout parameter in bordeaux- > > > > > > threads:condition- > > > > > > wait. > > > > > > (eval-when (:compile-toplevel :execute) > > > > > > ;; use special to defeat compiler analysis > > > > > > (defparameter *condition-wait* #'bordeaux- > > > > > > threads:condition- > > > > > > wait) > > > > > > > > > > > > (flet ((has-condition-wait-timeout-p () > > > > > > ... > > > > > > > > > > I tried to minimise this to a small standalone piece > > > > > which can be used to examine the issue: > > > > > > > > > > (ql:quickload :bordeaux-threads) > > > > > > > > > > (let ((lock (bordeaux-threads:make-lock)) > > > > > (cvar (bordeaux-threads:make-condition-variable))) > > > > > (bordeaux-threads:with-lock-held (lock) > > > > > (bordeaux-threads:condition-wait cvar lock :timeout > > > > > 0.001))) > > > > > > > > > > I think the :timeout doesn't seem to work properly and thus > > > > > the > > > > > condition-wait waits forever. > > > > > > > > > > Can you help me to understand this better and to work around > > > > > it ? > > > > > > > > > > Regards > > > > > Robert Larice > > > > > > > > > > > > > > > Robert Larice <robert.lar...@t-online.de> writes: > > > > > > > > > > > Hello, > > > > > > > > > > > > can you provide me some hints for the following problem ? > > > > > > > > > > > > I've compiled ecl from git on a debian stretch machine. > > > > > > Then I've tried to compile the "qt" example, > > > > > > which did hang when loading "lparallel" > > > > > > So I started "ecl" from a shell, > > > > > > and did execute > > > > > > (ql:quickload :lparallel) > > > > > > which presents me: > > > > > > > To load "lparallel": > > > > > > > Load 1 ASDF system: > > > > > > > lparallel > > > > > > > ; Loading "lparallel" > > > > > > then the process fell silent. > > > > > > "top" doesn't show "ecl" to consume cpu cycles. > > > > > > Its waiting for something and doesn't proceed. > > > > > > > > > > > > Regards, > > > > > > Robert Larice
