On Fri, Aug 21, 2009 at 2:27 AM, Juanjo < juanjose.garciarip...@googlemail.com> wrote:
> > 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<http://www.lispworks.com/documentation/HyperSpec/Front/%0AContents.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 It isn't. There must have been some other corruption of the stack. There is no code in all of Sage that directly calls anything in ECL. --- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
