freenode/#sbcl - IRC Chatlog
Search
23:08:45
sveit
hi. I am interfacing with some code through the first that requires a callback. sbcl has a very nice feature for this, sb-alien::alien-lambda
23:09:29
sveit
the problem I am running into is that it does not seem these lambdas will get garbage collected when they are no longer referenced
23:11:58
sveit
the problem is that I am calling this function many times, so many internal lambdas are created
23:13:26
sveit
I need to pass lisp functions to the C (actually Fortran, but that isn't important) code over and over again to be called in a numerical routine
23:14:34
sveit
for example, if I have a numerical integration routine in C that takes a function pointer, and I want to use it to integrate a huge number of lisp functions
23:15:38
sveit
what I currently do is have a lisp function that takes a lisp function as one of its arguments, then wraps that in a sb-alien::alien-lambda inside the body
23:17:23
sveit
one option I considered is to have a global variable *lisp-function*, then only create a single callback that funcalls the function in that variable, but I do not know how to make that work with many threads
23:21:06
sveit
you mean (let ((*global-var* f)) ... use callback), right? is this "threadsafe" in SBCL?
23:23:05
stassats
(defun make-alien-closure (target) (values (sb-alien::alien-lambda void () (funcall target)) (lambda (new-target) (setf target new-target))))
23:25:48
sveit
oh thanks, I haven't seen that trick before. I guess for each thread I still have to make a new closure, correct?
23:28:12
sveit
I guess if I play with locks (and global variables) I can have just a single callback
23:30:56
sveit
yeah, you're right. I'll think about this some more, thanks a lot for your help. is there any hope to make the alien-lambda "truly" garbage-collectible?
23:32:46
sveit
but I can still free up that memory and use it for other things when it comes to actual objects
23:46:43
sveit
hmm? so even if I invalidate the callback I will still get a new trampoline for every new lambda?
0:00:56
sveit
so how would my own pool solve this? or do you just mean to allocate several closure-style callbacks as you mentioned?
0:03:44
sveit
ok thanks. so to confirm you mean a pool of your "closure"-based callbacks? last question, thanks very much for your insight
0:06:03
sveit
yes, I got that part :) if I have some time someday I've always thought SBCL was incredible, maybe I can try to contribute a modification of the trampoline allocation to make them "freeable"
0:09:27
stassats
then move the argument marshalling code into the actual function - it'll be faster and avoid boxing/unboxing values
0:17:12
sveit
actually, I am looking at the documentation for dynamic bindings with threads, and it seems to say (13.2) that they are correctly thread local
0:20:32
pkhuong
sveit: consider using threads to turn the inversion of control into a message buffer interface
0:31:50
sveit
stassats: sorry, I got disconnected, did you have a comment on the solution with dynamic binding?
0:34:04
sveit
does this mean I can make a single callback that (funcall *global-var*) and dynamically bind *global-var* in each thread to solve my issue without a pool?
0:34:18
sveit
so concretely, (define-alien-callback num-caller double-float ((x double-float)) (funcall *global-fun* x)), used like (let ((*global-fun* some-fun)) (alien-funcall "name" num-caller))
0:35:04
sveit
at least without a per-thread pool, of course I would still need a different global variable for each type of callback, or ones used simultaneously in the same thread
2:29:38
karlosz
okay, got access to ppc64 thanks to stylewarning. going to start an honest threads effort now...
7:03:57
White_Flame
When the stack overflows, "Control stack guard page temporarily disabled: proceed with caution". When the stack shrinks back to an acceptable size, is that guard page re-enabled?
7:56:07
stylewarning
I’m building sbcl master using a bootstrapped sbcl master on PPC64 and get a segfault
9:00:48
karlosz
don't want to make too much noise in stylewarning's room... it's still an in-progress port right? :)