On Aug 21, 2:08 am, Nils Bruin <nbr...@sfu.ca> wrote: > Thank you! Should I call that on any cl_object that lives outside ecl? > or only (as the name suggests) on the root of a cl_object tree?
If you have a single lisp object that links to all live data outside of ECL, then you need only register that object. As I said, that would simplify your life and speed up the garbage collection. > Can the garbage collector move allocated pieces around? (so, can > pointed become invalid for reasons other than deallocation?) No, the garbage collector is conservative, which means it does not move data and does its best at interpreting memory words as pointers or not. This garbage collector is indeed designed to coexist with C programs, where data is not expected to move. > Am I right in assuming that if a cl_ routine gives me back a cl_object > pointer, I can trust that this pointer will remain valid until the > next time that I call a cl_ routine? Yes, if you make sure that there is a life reference that the garbage collector can recognize, either with register_root or by storing the pointer in another life object. > Would threads invalidate that > assumption? Should I call ecl_register_root immediately after being > supplied with the pointer to ensure the object doesn't inadvertently > get deallocated? No, yo do not call register root on objects. You call them on static variables that you know that will contain references to lisp objects. Please remind this: STATIC variables. You should not register as valid root a variable that lives in the stack: that is already detected by the garbage collector. > Is there a corresponding ecl_deregister_root to be called when I no > longer need the object? No, because of what I said before: ecl_register_root is only scarcely used, and only for static variables. If you keep references to objects in the C stack, this will not be needed (as far as the garbage collector knows your thread) > Are you suggesting that I'd be better off allocating a vector or an a- > list in ecl and store any reference to an ecl structure in that and > address it using an index or a handle? That could definitely be > arranged. I would say that would simplify your life a lot. You could keep one such structure per Sage thread and pass them to the lisp environment so that it makes permanent references to them (perhaps storing them in a list of thread-local arrays). > The initial usage scenario I am thinking about is to first create a > cython class cl_object, > which wraps an essentially opaque pointer cl_object. > c_string_to_object can easily be wrapped to produce such objects, and > via write-to-string they are easily turned into strings as well. Sounds fine. > Once that works, one could gradually de-opaque-ify cl_object and > provide access to the different fields, depending on the type. Please do not do that! Use the standard accessors that Common Lisp provides (http://www.lispworks.com/documentation/HyperSpec/Front/ Contents.htm) For every standard Common Lisp function there is a C equivalent in ECL. If you access directly the slots of an object your code might suffer portability problems and might break with future releases of ECL. > Incidentally, I managed to attach gdb to sage to get a little insight > in the segfault that happens when sage with ecl shuts down: > > Program received signal SIGSEGV, Segmentation fault. > GC_free (p=0x1c584fc0) at malloc.c:412 > > backtrace: > > #0 GC_free (p=0x1c584fc0) at malloc.c:412 > #1 0x00002b5798868966 in ecl_dealloc (ptr=0x184) > at /usr/local/sage/4.1.1/spkg/build/ecl-9.4.1/src/src/c/alloc_2.d: > 265 > #2 0x00002b57790572e2 in > __pyx_pf_4sage_5rings_7integer_free_integer_pool ( > __pyx_self=<value optimized out>, unused=0x8) at sage/rings/ > integer.c:29479 > #3 0x00000000004933b5 in PyEval_EvalFrameEx (f=0x1c92d8d0, > throwflag=<value optimized out>) at Python/ceval.c:3690 > [...] Why is Sage calling an ECL function at all? Juanjo --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
