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]

Re: New smob interface


Ken Raeburn <raeburn@raeburn.org> writes:

> It looks good, but you lost me here:
>  
> > IMPORTANT NOTE: If the advanced user chooses to store GC:d data in his
> > malloced block and writes his own mark function, it is no longer
> > possible to use scm_make_smob!
> 
> After some thought, I came to the conclusion that you were referring
> to the ordering of initialization of the fields versus creating the
> SCM object(s), and how GC before all the fields get initialized would
> be bad.  If so, that should probably be mentioned in documentation on
> the New Way.  Probably with a reminder that new GC systems are being
> experimented with, so even though we don't have concurrent GC now, and
> GC might not be run during the object's initialization, we might get
> concurrent GC later, and that could break the user's code.

Right.

> Maybe scm_make_smob(my_type) should be SCM_NEWSMOB_SIMPLE(z,my_type)
> so that it looks similar to SCM_NEWSMOB, except that it doesn't need
> the pointer to the already-filled-in structure.  (It could of course
> be a macro expanding to a call to a scm_make_simple_smob or
> scm_make_uninitialized_smob function.  But I think the name
> "scm_make_smob" carries no implication that it's *not* safe for
> non-trivial objects.)  Either that, or SCM_NEWSMOB should return a
> value and not assign to an lvalue.

I'd like the naive user to be able to use a simple function.  If he
starts to use a mark function of his own design he anyway has to do a
lot of reading.  Therefore I don't see any big danger here.  We'll
just put a few big NOTEs at suiatble locations in the manual (like at
the scm_set_smob_mark function).

Also, note that SCM_NEWSMOB is to be used for implementing Guile
itself (this is actually the main task for the scm interface), so it
needs to be efficient.  (We wouldn't like to have unneccessary
overhead when allocating doubles, for example.)

At the same time I'd like to have maximum simplicity in the
implementation.  scm_make_smob is implemented using SCM_NEWSMOB.

Also note the parallels:

SCM_NEWCELL	<->	SCM_NEWSMOB
scm_cons	<->	scm_make_smob

I think it's pretty OK.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]