guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do we trust the man on the GC trigger?


From: Michael Livshin
Subject: Re: Do we trust the man on the GC trigger?
Date: 28 Aug 2001 20:18:41 +0300
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)

Michael Livshin <address@hidden> writes:

> Dirk Herrmann <address@hidden> writes:
> 
> > On 28 Aug 2001, Michael Livshin wrote:
> > 
> > > let's try a little thought experiment.  let's pretend that smob's size
> > > is part of the type, so there's no need for a user (or a Guile
> > > developer, for that matter) to manually allocate and deallocate smob
> > > data (in fact, I believe it's already the case: see `scm_make_smob').
> > 
> > I disagree:  We should not assume that each smob has an associated fixed
> > size with it.  It is an unnecessary restriction and would inhibit users
> > from providing home brewn vector types, auto resizing hash-tables
> > etc.  One could argue that either all these should be implemented using
> > goops, or that one day guile will provide all those features you could
> > probably think of anyway.  However, we are not that far:  goops does not
> > have a C interface yet, and guile does not yet provide all the features
> > you could think of :-)
> 
> OK.  my claim, basically, is this: most user smobs are fixed-size
> (don't ask me for references, it's a wild guess).  so this is the
> usage pattern the smob API should be optimized for.

one more thing: the `mtrigger' mechanism is, basically, a kludge.
it's there simply because vector/string/etc. data is allocated by
malloc (i.e. not on the Scheme heap), and thus some way is needed to
account for that.

there's no harm in not exposing it, really.  but we do need to get the
internal usage right.

-- 
The only thing better than TV with the sound off is Radio with the sound
off.
                -- Dave Moon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]