unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: guile-user@gnu.org
Cc: guile-devel@gnu.org
Subject: Re: GNU Guile 2.1.7 released (beta)
Date: Fri, 24 Feb 2017 15:02:21 +0100	[thread overview]
Message-ID: <87d1e7vg9e.fsf@pobox.com> (raw)
In-Reply-To: <87tw7kviu6.fsf@pobox.com> (Andy Wingo's message of "Thu, 23 Feb 2017 19:54:25 +0100")

On Thu 23 Feb 2017 19:54, Andy Wingo <wingo@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



  parent reply	other threads:[~2017-02-24 14:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-18 10:31 GNU Guile 2.1.7 released (beta) Andy Wingo
2017-02-18 14:34 ` GNU Guile 2.1.7 released (beta), SOCK_NONBLOCK Matt Wette
2017-02-21 20:58   ` Andy Wingo
2017-02-18 17:40 ` GNU Guile 2.1.7 released (beta) Matt Wette
2017-02-18 17:48 ` Matt Wette
2017-02-23 18:54 ` Andy Wingo
2017-02-23 20:04   ` Mike Gran
2017-02-23 21:06     ` Andy Wingo
2017-02-24  0:52     ` Break-when [was GNU Guile 2.1.7 released (beta)] Matt Wette
2017-02-24 14:02   ` Andy Wingo [this message]
2017-02-24 17:46   ` GNU Guile 2.1.7 released (beta) Arne Babenhauserheide
2017-02-26 17:57     ` Andy Wingo
2017-02-27 19:32       ` Mike Gran
2017-02-27 20:30         ` Andy Wingo
2017-02-27 23:00       ` Thomas Morley
2017-02-28  8:31         ` Andy Wingo
2017-03-05 16:54           ` Thomas Morley
2017-03-01 18:04       ` Arne Babenhauserheide
2017-02-28  0:04   ` David Pirotte
2017-02-28  1:49     ` Daniel Llorens
2017-03-02 20:54       ` David Pirotte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1e7vg9e.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).