Re: Can the Guile library be reentrant

[John Tobey <jtobey@channel1.com>]

I'm about to rant, so let me start by thanking Jim and the other Guile
developers for writing such a nice bunch of code and mostly
documenting it and making even the snapshots build fairly cleanly and
making me feel accepted in your community even though I have as yet
contributed little other than a few random thoughts and questions.

> Guile could provide another initialization function that accepts the
> address of the base of the stack as an argument, but I really don't
> trust people to use that reliably.

"Base"--yes, that's the word I wanted.  Thank you.  I can never tell
if I should be standing on my head when referring to the "top of the
stack."  :-)

> 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.

> > Come to think of it, this could be beneficial if the application knows
> > it won't store SCMs above point x in the call stack.  Why scan above a
> > frame which both initializes and destroys the interpreter?
> 
> 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."  Is
it that Guile users are too ignorant to know what the stack
base/top/bottom is or why it is important to Guile?  Such a user
should think twice before attempting to embed an interpreter in a C
program.

Frankly, I won't take an "embedded" language seriously unless it
respects my ownership of the process in which I run it.  Specifically,
unless I explicitly ask for it, or it happens under strictly
controlled and well-documented circumstances, the library should not:

  - call exit()
  - alter or install any signal handlers
  - use or manipulate the standard I/O streams (even stderr!!)
  - change the working directory
  - alter the umask, pgrp, uid, or any other per-process variable

I'll grudgingly allow it to call malloc() and free(), though I'd
prefer to be able to monitor and limit even that.

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.  If the program
or the operating system has a way for me to find the stack base, I
should be allowed to use it to my advantage.

All right.  End of rant.  Think happy thoughts...

> 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?

-John