This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Marius Vollmer <mvo@zagadka.ping.de> writes: > Greg Harvey <Greg.Harvey@thezone.net> writes: > > > > You mean, I could just let the proxy/widget move into a guardian when > > > there are no references to it from Scheme and then, after the GC, do > > > the internal reference boogie to find out which of them are really > > > dead and resurrect the rest? Yes, that could work. It would be > > > basically the same as what I'm doing now, but probably more efficient. > > > > Actually, you could just slap it into a guardian from the beginning, > > and look at the dead ones after collection. If they aren't really > > dead, put them back into the guardian. > > I don't know how guardians really work... Basically, they're like a generalization of weak pointers, except instead of freeing objects that aren't traced, it marks them and puts them in the zombie portion on the guardian, so that you can do what you like with the objects that died (and they live on until you retrieve them). As an example, say you wanted to reimplement weak vectors; you could create a new object type that contained a vector of SCM's (but didn't trace the values in it) and a guardian, which would contain each of the values added to the weak vector (or, more likely, a pair, so that you could get to the index of the object quickly). After a collection, you'd just drop all of the zombie objects, and shift around the vector. It's quite a schemy notion, really, being somewhat abstract and allowing you to implement all sorts of funky data structures. There is a paper out there somewhere, but I can't remember where I got it (probably at www.schemers.org) > > Here's how I understand it: you have a widget foo, that you just > > created. On the gtk side of things, it keeps a reference count; on the > > scheme side of things, you put the scheme object of the widget into > > the widget guardian. You do a bunch of stuff, and then all references > > to foo's scheme object are dropped. On the next collection, foo > > becomes a zombie. After that, you look at the widget zombies. foo > > still has a gtk refcount greater than 1, so you put foo back into the > > guardian. > > Almost. I have to look if that widget has a refcount greater than its > internal refcount, to defeat cycles. Finding the internal refcount > involves running over all widgets in the guardian, whether zombie or > not. This can be avoided when there are no zombies in the guardian > which would be a win over the current scheme. But I think guardians > have their cost, too, no? > Without looking at the code, I'd figure that the cost of the guardian stuff is basically just the cost of the number of objects being guarded (it will have to look through between marking and sweeping to figure out which objects weren't traced, then do a mark on them to prevent them from being freed, then put them in a queue). More than performance boosts, though, it might be more convienient to do it with built-in features, rather than having to roll your own; at this point, though, it's probably not worth the trouble it would take to modify guile-gtk to use guardians. -- Greg