Re: GDL2, garbage collection, and threads

[David Ayers]

Hello Scott,

Please excuse me for replying so late.  My mail box is so full of 
clutter, that I seemed to have missed your mail (eventough GDL2 is right 
there in the subject)...

Scott Anderson wrote:

> I'm looking at using GDL2. In reading through the only documentation I 
> could find (for GDL, ca. 1997 or so), there is a reference to using 
> garbage collection to avoid memory leaks with cyclic models. 

GDL2 is still using a special GC collection mechanism, even though I'm 
hoping that we won't need it sometime in the future, but that seems a 
bit off right now.   (I say "special" as it is different from the 
"ordinary" mechanism supplied by configuring base with the GC option.)

> However, there is also a note to the effect that the GC implementation 
> is not thread-safe. Since the program I'm working on will be heavily 
> threaded, and I need db access, what are my options? Are the docs 
> (hopefully) out of date? 

When it comes to GC in GDL2 there are thread safety mechanisms in 
place.  (Thanks Richard :-) )  Yet I presume that there plenty of other 
potential thread safety related pitfalls currently in GDL2.  But 
probably none, that a reasonable carefully designed app shouldn't be 
able to avoid.  In fact I believe GSWeb apps can be used reasonably safe 
in a mutlithreaded environment.

> In looking at the GC code, I notice that it is all class methods. Is 
> there any benefit to rewriting it as instantiable objects, so each 
> thread could have its own GC? 

I'm not sure what you mean.  Yes, the GC-handling methods are class 
methods, but they could as well have been functions (or maybe even 
instance methods, except then you would always need some instance to do 
the handling.)  The actual garbage collectable objects are instances of 
GCObject subclasses.

Now all of this is indepenent of a per thread GC pass.  An object isn't 
owned by a thread.  GC in this case isn't real reference counting like 
classic GC, it is rather a "retain count correction" to break cyclic 
references, to release objects in a graph that are merely retaining 
themselves.  If some code which is being executed by a thread, needs an 
object, it must make sure the object is retained during it's execution.  
It should be as simple as that.

Maybe you can specify a bit more what your worries really are.  I 
believe it would make sense to first try a make single threaded app 
using GDL2 (you'll most likely stumble across some other issues here 
already, that I would be glad to help solve)  and we can look at GDL2's 
thread safety in a second step.  I think the thread safety of GC is the 
least of our worries.  There are other places where GDL2 access global 
resources that aren't protected by lock yet.  Maybe you can help audit 
those.

Cheers,
David