id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc
1052,Foreign callbacks into a thread which is about to die,stassats,,"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
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.",defect,closed,normal,,"Runtime (threads, GC)",trunk,fixed,,