Using usocket:wait-for-input gets USOCKET:UNKNOWN-ERROR is bt:condition-wait is used elsewhere with a :timeout
The title describes the problem. In ECL I get an error on a socket if on another thread there is a condition-wait with a timeout going on. The code below reproduces it for me consistently on ECL (Embeddable Common-Lisp) 16.1.3 (git:963396cb4b79f2a4740114ce76c87787fb83d3da)
(require :asdf)
(require :bordeaux-threads)
(require :usocket)
(defvar *thread*)
(defparameter *lock* (bt:make-lock "test-loop-lock"))
(defparameter *condition* (bt:make-condition-variable :name "test-loop-condition"))
(defun test-wait ()
(sleep 2)
(bt:acquire-lock *lock*)
(loop
do (unless (bt:condition-wait *condition* *lock* :timeout 1)
(bt:acquire-lock *lock*))))
(setf *thread*
(bt:make-thread #'(lambda () (test-wait)) :name "test-wait-loop"))
(let ((socket (usocket:socket-connect nil nil
:protocol :datagram
:local-host "127.0.0.1"
:local-port 12777
:element-type '(unsigned-byte 8))))
(usocket:wait-for-input `(,socket) :ready-only t))
;; loading this will result in '; Evaluation aborted on #<a USOCKET:UNKNOWN-ERROR>.'
;; within a couple of seconds (~10)
Expected result is of course not getting an error out of nowhere.
My setup:
CL-USER> (lisp-implementation-version)
"16.1.3"
CL-USER> (ext:lisp-implementation-vcs-id)
"963396cb4b79f2a4740114ce76c87787fb83d3da"
CL-USER> (software-type)
"Linux"
CL-USER> (software-version)
"4.19.27-gentoo-r1"
CL-USER> (machine-type)
"x86_64"
CL-USER> *features*
(:SPLIT-SEQUENCE :BORDEAUX-THREADS :THREAD-SUPPORT :SWANK :SERVE-EVENT
:QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
:NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :WALKER :CDR-1 :CDR-5 :LINUX :FORMATTER
:CDR-7 :ECL-WEAK-HASH :LITTLE-ENDIAN :LONG-LONG :UINT64-T :UINT32-T :UINT16-T
:COMPLEX-FLOAT :LONG-FLOAT :UNICODE :DFFI :CLOS-STREAMS :CMU-FORMAT :UNIX
:ECL-PDE :DLOPEN :CLOS :THREADS :BOEHM-GC :ANSI-CL :COMMON-LISP
:IEEE-FLOATING-POINT :PACKAGE-LOCAL-NICKNAMES :CDR-14 :PREFIXED-API :FFI
:X86_64 :COMMON :ECL)
I may be wildly off-base here, but could #420 have anything to do with this?