Custom Query (1030 matches)
Results (889 - 891 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1049 | fixed | Bug in construct-setf-function-name | ||
| Description |
In level-1/l1-aprims.lisp, construct-setf-function-name should also test for #\" in the package-name, or it will confuse packages named ":" and "\":\"". |
|||
| #1050 | fixed | Bad file descriptor error in accept or bind or listen | ||
| Description |
(defun run-server (host port out)
(with-open-stream (server (ccl:make-socket :connect :passive
:local-host host
:local-port port
:reuse-address t))
(with-open-stream (stream (ccl:accept-connection server))
(format out "~s~%" (read stream))
(print :pong stream)
(finish-output stream))))
(defun make-socket/retry (host port tries)
(loop (handler-case (return (ccl:make-socket :remote-host host
:remote-port port))
(ccl:socket-creation-error (err)
(unless (plusp (decf tries)) (error err))
(format t "retry~%")
(sleep 0.1)))))
(defun test (host port)
(ccl:process-run-function "server" #'run-server
host port *standard-output*)
;(sleep 0.001)
(with-open-stream (stream (make-socket/retry host port 5))
(print :ping stream)
(finish-output stream)
(format t "~s~%" (read stream))))
(defun run ()
(loop for port from 10000 to 20000 do (test "localhost" port)))
Failure happens within three iterations on my machine. retry :PING :PONG retry > Error: on #<CCL::LISTENER-SOCKET #x1866FB36> : > Bad file descriptor (error #9) during accept > While executing: SOCKET-ERROR, in process server(3). or retry :PING :PONG retry > Error: Bad file descriptor (error #9) during socket creation operation in bind > While executing: SOCKET-ERROR, in process server(3). or retry :PING :PONG retry :PING :PONG retry > Error: Bad file descriptor (error #9) during socket creation operation in listen > While executing: SOCKET-ERROR, in process server(4). Adding the SLEEP call after PROCESS-RUN-FUNCTION prevents all errors. Tested on 1.9-dev-r15576M-trunk (LinuxX8632). Failure on Darwin has happened but is very rare; I've only seen it twice. I can work around this issue by handling/retrying, however CCL is the only implementation which requires this special attention. |
|||
| #1052 | fixed | Foreign callbacks into a thread which is about to die | ||
| Description |
Qt-webkit uses pthread_key_create with a destructor, and inside that destructor it calls back into lisp. But apparently lisp-thread infrastructure is already dismantled when the destructor is called. Here's a test-case: // gcc test.c -lpthread -shared -o test.so -fPIC
#include <pthread.h>
void finish(void* arg) {
int (*f)(int, int) = (int(*)(int,int))arg;
f(1,2);
}
int test (int (*f)(int, int))
{
pthread_key_t key;
pthread_key_create(&key, finish);
pthread_setspecific(key, f);
}
(eval-when (:compile-toplevel :load-toplevel :execute)
(asdf:load-system :cffi))
(cffi:load-foreign-library "/tmp/test.so")
(cffi:defcfun (test-c "test") :int
(function :pointer))
(cffi:defcallback (test-callback)
:short ((a :int) (b :int))
(print (list a b))
(finish-output)
1)
(defun test ()
(ccl:process-run-function
nil
(lambda () (test-c (cffi:get-callback 'test-callback)))))
(test)
One idea I had for fixing this is creating a new thread-key with a value of 1. The order of destructor execution is not specified, but it's specified that they are called PTHREAD_DESTRUCTOR_ITERATIONS times if the key still has a value. So, when the destructor is called the first time, it'll just set its value to 0 and do nothing, then when it's called with 0, do thread clean up. That way other key destructor will get a chance to be called on the first iteration before the clean up is completed. |
|||
