Loading "lparallel" hangs

[Daniel Kochmański]

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 <daniel at 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 <daniel at 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.Larice at 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