Hi folks,
I'm receiving the following warning messages in the *slime-repl sbcl* buffer after updating to the latest CVS yesterday:
WARNING: Releasing #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :LUTEX #<unknown pointer object, widetag=#x5E {120B1017}>), owned by another thread: NIL
This message occurs many times a second and quickly populates the buffer with thousands of lines. I was able to reproduce this issue with SBCL 1.0.18 and 1.0.19 on Darwin x86 (Mac OS X 10.5.4).
Regards,
- Scott Bell
Scott Bell scott.bell@me.com writes:
I'm receiving the following warning messages in the *slime-repl sbcl* buffer after updating to the latest CVS yesterday:
WARNING: Releasing #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :LUTEX #<unknown pointer object, widetag=#x5E {120B1017}>), owned by another thread: NIL
This message occurs many times a second and quickly populates the buffer with thousands of lines. I was able to reproduce this issue with SBCL 1.0.18 and 1.0.19 on Darwin x86 (Mac OS X 10.5.4).
That seems to be an a sbcl-issue, see a workaround by Helmut:
http://thread.gmane.org/gmane.lisp.slime.devel/7529
Regards,
- Scott Bell
okflo
* Scott Bell [2008-08-26 22:00+0200] writes:
Hi folks,
I'm receiving the following warning messages in the *slime-repl sbcl* buffer after updating to the latest CVS yesterday:
WARNING: Releasing #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :LUTEX #<unknown pointer object, widetag=#x5E {120B1017}>), owned by another thread: NIL
This message occurs many times a second and quickly populates the buffer with thousands of lines. I was able to reproduce this issue with SBCL 1.0.18 and 1.0.19 on Darwin x86 (Mac OS X 10.5.4).
Could you do me a favor? Do you also see the warning for a simple test case like this:
(progn (defvar *mutex* (sb-thread:make-mutex)) (defvar *waitqueue* (sb-thread:make-waitqueue)) (loop (sb-thread:with-mutex (*mutex*) (format t "sleeping..~%") (sleep 0.1) (handler-case (sb-ext:with-timeout 0.2 (sb-thread:condition-wait *waitqueue* *mutex*)) (sb-ext:timeout ())))))
If so, could you report it as a SBCL bug? And if you are at it, also convince the SBCL gods that CONDITION-WAIT should take a timeout argument directly, because that would be more efficient and less problematic than WITH-TIMEOUT. Thanks.
Helmut.
In article m27ia249rr.fsf@common-lisp.net, Helmut Eller heller@common-lisp.net wrote:
(progn (defvar *mutex* (sb-thread:make-mutex)) (defvar *waitqueue* (sb-thread:make-waitqueue)) (loop (sb-thread:with-mutex (*mutex*) (format t "sleeping..~%") (sleep 0.1) (handler-case (sb-ext:with-timeout 0.2 (sb-thread:condition-wait *waitqueue* *mutex*)) (sb-ext:timeout ())))))
Using progn instead of loop -> uname -a Darwin karsten-poecks-macbook-pro.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386
* (lisp-implementation-type)
"SBCL" * (lisp-implementation-version)
"1.0.19" * (progn (defvar *mutex* (sb-thread:make-mutex)) (defvar *waitqueue* (sb-thread:make-waitqueue)) (progn (sb-thread:with-mutex (*mutex*) (format t "sleeping..~%") (sleep 0.1) (handler-case (sb-ext:with-timeout 0.2 (sb-thread:condition-wait *waitqueue* *mutex*)) (sb-ext:timeout ()))))) ; in: LAMBDA NIL ; (SB-THREAD:CONDITION-WAIT *WAITQUEUE* *MUTEX*) ; ==> ; *WAITQUEUE* ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 1 note sleeping.. WARNING: Releasing #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :LUTEX #<unknown pointer object, widetag=#x5E {116E3C87}>), owned by another thread: NIL
With loop I get more of this warnings until sbcl finally hangs.
What are you trying to achieve here, perhaps there is another way to achieve the same?
Karsten
* Karsten Poeck [2008-08-27 21:46+0200] writes:
What are you trying to achieve here, perhaps there is another way to achieve the same?
I'm trying to wait for a condition to become true or a timeout, whatever comes first.
Helmut.
On Wed, Aug 27, 2008 at 9:01 PM, Helmut Eller heller@common-lisp.net wrote:
If so, could you report it as a SBCL bug?
I think I know what the bug is -- not the details, but the general shape, if you will. The problem is with interrupted pthread_foo calls on lutex platforms (or possibly only Darwin.)
And if you are at it, also convince the SBCL gods that CONDITION-WAIT should take a timeout argument directly, because that would be more efficient and less problematic than WITH-TIMEOUT. Thanks.
That is in the plans, however, it requires re-implementing a lot of stuff since Darwin does not support timeout variants for various pthread functions -- so it will take a while to happen.
Cheers,
-- Nikodemus
On Thu, Aug 28, 2008 at 9:45 AM, Nikodemus Siivola nikodemus@random-state.net wrote:
That is in the plans, however, it requires re-implementing a lot of stuff since Darwin does not support timeout variants for various pthread functions -- so it will take a while to happen.
Nikodemus, apologies for my naiveté, but is it not sufficient for have pthread_cond_timedwait in this situation?
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/pthr...
Regards,
- Scott Bell
On Thu, Aug 28, 2008 at 7:21 PM, Scott Bell sebell@gmail.com wrote:
Nikodemus, apologies for my naiveté, but is it not sufficient for have pthread_cond_timedwait in this situation?
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/pthr...
No, sorry for my bogus knowledge. Last time I checked, which was probably during 10.4, the only timed wait I found was the IIRC SemaphoreWait or similar which did not like SBCL at all. (Mysterious messages to terminal is not usually a good sign...)
Cheers,
-- Nikodemus
-
Helmut Eller -
Karsten Poeck -
Nikodemus Siivola -
okflo＠diesenbacher.net -
Scott Bell -
Scott Bell