Re: Can the Guile library be reentrant

[Jim Blandy <jimb@red-bean.com>]

> > Probably the best approach is to continue to provide gh_enter-style
> > initialization, and then provide another function which uses whatever
> > system-specific tactics it can scrounge together, and prints an error
> > message if it can't figure out your system.  That way, we can
> > gradually acquire expertise, while still ensuring that Guile operates
> > reliably.
> 
> So... rather than give the user a chance to solve cleanly what we
> can't solve ourselves, we hack together a non-portable band-aid fix.

Yes, exactly.  If everyone would just pitch in their little bit of
misery, think what a world this would be.

Well, no.  I guess my thought was this: there *is* no portable
solution, inside or outside of Guile.  So, is it better to encourage
each user to invent the solution afresh themselves, and distribute
code which crashes mysteriously on every system but their own (said
crashes will be blamed on Guile, mind you), or is it better to have
people contribute patches to the Guile init function to make it work
on their system, and have all the expertise and hacking accumulate in
one place, where everyone benefits?


> > This is begging for trouble.  Remember that GC-related bugs are
> > intermittent, and very hard to track down.
> 
> This is the sort of reasoning I imagine goes on in Redmond.  "We know
> our code is broken.  We don't want to fix it.  Let's make it hard for
> the user to do things which might expose our weakness and hope they
> don't ask for the features we'll be sacrificing in the process."

Hmm.  I'll just observe that that is not actually the reasoning that I
followed, so you must have come up with it yourself. :)

I realize that it's politically iffy to say, "I don't want to provide
this feature because I think it will be used erroneously, to little
benefit."  The person who proposed the feature certainly sees benefit
in it, leaving them with the implication that I think they,
specifically, will use it erronously.

However:

1) When I say something is difficult to use, I mean that I doubt that
*I* would use it correctly.  For example, Emacs's GC protection system
avoids the need to know the stack base altogether.  And it could be
used for copying collectors, unlike Guile's.  However, Emacs's GC is
so hard to use correctly that *I* frequently got it wrong when I was
the full-time Emacs maintainer for GNU, and Richard Stallman also
frequently got it wrong.  Every release of Emacs 19 had GC-related
bugs because of this.

Now, if Stallman can't get something right, even then I would not
necessarily refuse to provide the feature.  Sometimes it's okay to
say, "Hey, use this at your own risk."  But if the feature is
something like the initialization function, which everyone must use,
and which you must get right if you want to avoid mysterious
segfaults, then I'm not cool with that.  (The gh_enter - style
initialization annoys enough people that I think it will be basically
abandoned.)

2) The feature at hand (allowing the user to say which stack frames
contain heap references) is a microoptimization.  I don't think it'll
make any significant difference in the speed of Guile, since scanning
the stack is not a major expense.  Marking the heap takes much longer.


> In short, I would like to be able to use Guile in a program whose
> internals I know nothing about and which has no knowledge of Guile.
> For example, in a Netscape plugin or an Apache module.

I certainly would like to see Guile used in these applications.
Finding the stack base is a problem there, and I've already said that
I'm interested in providing a more traditional init function.  But
beyond that issue, I don't see that Guile is as invasive as you claim.

> > Okay, this is on the post-1.3 to-do list.
> 
> I hope by "this" you mean a long-term, acceptable solution to the
> whole reentrancy and embedability problem.  Yes?

Aside from the stack base question, are there other specific
embeddability problems you could point out?