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
