Custom Query (1030 matches)
Results (955 - 957 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #787 | fixed | ccl:arglist interns into the current package | ||
| Description |
When used on macros, ccl:arglist interns symbols from the lambda list into the current package: (defpackage :foo (:use :cl)) #<Package "FOO"> ? (in-package :foo) #<Package "FOO"> ? (defmacro bar (bar10)) ;Compiler warnings : ; In BAR: Unused lexical variable BAR10 BAR ? (in-package :cl-user) #<Package "COMMON-LISP-USER"> ? (find-symbol "BAR10") NIL NIL ? (ccl:arglist 'foo::bar t) (BAR10) :DECLARATION ? (find-symbol "BAR10") BAR10 :INTERNAL |
|||
| #1038 | fixed | latin-1-unix not recognized as a valid encoding in -*- coding: -*- | ||
| Description |
;;; -*- coding: latin-1-unix -*- causes Unknown character encoding: :LATIN-1. That's because it expects LATIN1, but I'd also say that it shouldn't throw an error even if it's not recognized, just a warning. |
|||
| #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. |
|||
