Hi Rémi,

I have got a bit of time finally! I'll try to take again this thread.

A Dimecres 01 Febrer 2006 09:51, [EMAIL PROTECTED] va escriure:
[...]
> To my mind the function that create Arrays is correct : the Array returned
> can be correctly read.
> It can even be called several times without any problems.
> But there's a problem with the garbage collector. Here an other test I made
>
> [...]
>
> >>> a = array1.attrs.createArFromRef(array2.get_reference())
> >>> a = "a"
>
> here I get a segmentation fault : the Array stored under the variable a
> can't be deleted properly (Although the function tables.Node.__del__ seems
> to work fine with my Arrays)

Yes. It seems like if the __del__() call is creating some problems,
but I don't know exactly why. IMO, you should not call directly
node.__del__() unless you have a *very good* reason to do that. Why
you cannot direct the PyTables LRU cache do that automatically by
calling the .close() method?

I've managed to create a script (based on your test units) that
reproduces a segfault (see the attachment). With this, there are some
things that I don't quite understand:

- Why do you need to implement an AttributeSet.__getattribute__()
  method if you already have an AttributeSet.__getattr__().

- Also, it seems that the second time that you access the
  DIMENSION_LIST attribute, you need to close all the nodes referenced
  by it. Why so?
  
- Finally, why do you use ds.__del__() directly? If you really want to
  close the ds node, why not use ds.close()?
  
I think that the biggest problem here is that I don't fully understand
how you have implemented the dimension scales, so until I do, I can be
of little help.

> Maybe a solution could be to store each Array created through this function
> in a new argument (something which would looks like
> tables.File._aliveNodesor tables.File._deadNodes). Thus the Array created
> would not be collected by the garbage collector.
> But I wonder what would happen when the file would be closed : it would be
> useless to store this argument in the hdf5 file, so it would eventually be
> discarded. What would happen then ?

Sorry, but I don't quite understand your point here. File._aliveNodes
and File._deadNodes indeed are dictionaries that keep weak references
to nodes. Of course, you can define one of this for storing references
as well, but the thing that I don't understand is why you may want to
save it persistently in the hdf5 file. Shouldn't this dictionary be
created in opening time?.

Again, I've tried to look into your code, but I very much miss a
document explaining what you are trying to do exactly and how. In this
way, not only me, but other people in the list would be able to grasp
the main points of your implementation of the dimension scales and be
able to help you.

For this reason, I've created a wiki page (in the prototype of future
PyTables wiki) where you can start documenting dimension scales. There
you can put your design goals, which is your approach, which are your
main problems... This way, other people would be able to contribute
ideas by modifying/updating this page. I really think that it would be
a good thing to attract interest in this specific project.

If you also think this is a good idea and want to give this wiki page
a try, then go to:

http://pytables.carabos.com/moin/DimensionScales

and create an account for you (login button) and voilà, you can start
documenting your dimension scales implementation. With a bit of luck,
some of us would be able to better realize your current work and be
able to better help on this.

Cheers,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"

Attachment: crash.py
Description: application/python

Reply via email to