On Thu 23 Feb 2017 19:54, Andy Wingo <wi...@pobox.com> writes: > * Foreign objects. In or out? Let's start a subthread.
SMOBs have many problems: * they are limited in number (255 including guile's smobs) * SMOB types are only creatable from C (in a time where anything done in C should be doable in Scheme) * SMOBs can only be constructed from C * SMOB fields are only accessible from C * SMOB markers are ~~~~~~gnarly~~~~~~~ * SMOB finalizers are tricky. Well finalizers are tricky in general but for SMOBs specifically they can see other objects that have already been finalized (or which are being concurrently finalized) and thus have called their own free() functions, which can corrupt memory. The situation with SMOBs is good if you don't specify mark procedures (practically deprecated since Guile 1.8) and your finalizer doesn't touch additional GC-managed objects that themselves have finalizers (hard to determine) and if your finalizers are threadsafe (ha ha ha ha ha ha). The manual didn't really discuss any of these problems. And then there's the issue of the very 1980s interface of SMOBs. Let's not mention markers! So you look at this whole situation and, this is an interface headed for deprecation, right? I mean surely we can do better -- or at the very least we can do the same but in a more comprehensible way. So I made the "foreign object" interface to do just that. See the docs here: https://www.gnu.org/software/guile/docs/master/guile.html/Defining-New-Foreign-Object-Types.html https://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Objects.html The former is in the introductory "using Guile from C" section and the latter is the reference. Compare to 2.0: https://www.gnu.org/software/guile/manual/html_node/Defining-New-Types-_0028Smobs_0029.html - it tells users to use mark functions (this is bad advice in general) - it doesn't mention much about threads when it talks about finalization https://www.gnu.org/software/guile/manual/html_node/Smobs.html#Smobs - not really linked to from the previous section?? (This one is in "API" and the other is in "Programming in C") - recommending scm_gc_free - scm_markcdr???? So foreign objects fixes the problems mentioned above and also makes the whole facility more explainable. It effectively replaces SMOBs; it's a nicer interface in all regards. I think it would be fine to continue having foreign objects going forwards. It's supportable just fine and strictly better than smobs (unless you need a mark function, in which case SMOBs are still there for you). It could be that these foreign objects don't fulfill all use cases, such as packed structs with C layouts. Oh well; can't win them all. We can work on this more in the future I think. Thoughts? :) Andy
