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: > Let me drone on a little bit. I read your discussion with great interest, because I have given this problem a bit of thought myself in the context of some of the programs I've written that use guile, and that also have to play nice with external systems that do their own resource management. What is interesting to me about your strategy is that it attempts to share the responsibility for the lifetime of an object between the Scheme world and the outside world. Generally I have given up and given ultimate control of an object's lifetime to one of the two worlds. From your description, it sounds like the in-between strategy can work, with a signficant amount of additional complexity. GTK widgets are an interesting application for this idea, because AFAIK, the object's lifetimes really are determined outside of the Scheme world's domain, because the user can tell the X server to nuke a particular window at any time. What does it mean then to have a live Scheme object representing a GTK widget, if that widget's window is gone? At that point, a nonzero reference count still doesn't leave you with a useful object. It seems likely that my understanding of your strategy is incomplete somehow. If the Scheme world is in charge of the lifetime of a resource, then life is simple, and the facilities of guile are perfect. smob mark and free functions are all you need. What about the situation when the lifetime of the object is decided outside of Scheme? Then it's possible, or even likely that captured references to these object will become stale at some point. The approach I have adopted is stolen from Emacs's buffer handling. In Emacs, Lisp buffer objects can point to buffers that have been destroyed, which are called dead buffers. The Lisp programmer just has to be ready to handle this case, which in practice doesn't make things that much harder or inconvenient. Of course, there has to be some way to determine whether the resource is question is dead or alive. In all of the situations where I've used this technique, there was some way to receive notifications of an object's demise, so that the smob structure could be updated to reflect the object's morbidity. It may be necessary to track all of the structures that have been boxed and exported to Scheme for this to work (usually this can be done with a hash table). So if I were writing a GTK interface, I would have just used 'widget-live?' or some such. Maybe this is a loser for some reasons that I'm missing, but the strategy has worked for me in other contexts. -russ -- Aim for the impossible and you will achieve the improbable.