Re: Can the Guile library be reentrant

[Telford Tendys <telford@triangle.triode.net.au>]

> > 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
                         ^^^^^^^^^^^^^^^^^^^^^^^^
Jim doesn't actually believe that it is POSSIBLE to fix it.
I feel that there might be some value in taking a step back away
from the problem and consider what alternatives there are.

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

We are happy to admit our weakness and even make a lame attempt at a fix.

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

So far (crosses fingers) I have found it quite usable.

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

All the user is saying is, ``nothing below this contains SCM variables
on the stack''. That is the same as saying, ``I'm calling my first scheme
function right here and I promise not to keep it's return value to my
next invocation of a scheme function''.

For example, consider a function:
void gh_eval_string_no_result( const char *blah );

You are not passing in any SCM values and not getting any back.
Suppose that guile checks it's top of stack marker, finds that it
doesn't have one and so sets it to something inside the above function
(but clears it on the way out). Recursive calls of the above function
would leave the marker alone but repeated calls without recursion
would set the marker each time.

There are two main differences between the above proposal and what
we have. Firstly, gh_enter goes through a bunch of slow initialisation
things (which COULD be split into a separate entry point) and secondly
gh_enter doesn't return. From the source code:

``  If you try to
   manipulate SCM values after this function returns, it's the luck of
   the draw whether the GC will be able to find the objects you
   allocate.  So, scm_boot_guile function exits, rather than
   returning, to discourage people from making that mistake.   ''

As I said above, the real promise made by the user is not to use
SCM values after the function returns. OK, I'll buy your argument
about bugs being blamed on guile and trouble comming from installing
traps and gotchas and users getting frustrated by complicated and non-portable
APIs. _HOWEVER_, if the users of guile are so foolish that you can't
trust them with a simple thing like, ``don't use SCM values after this
returns,'' then where exactly is this project headed?

I mean, we could decide that returning a pointer to a local variable
was so dangerous that we must not trust users with any local variables,
or for that matter, any pointers -- brilliant!

These are C programmers you are talking to, not Java programmers
<that was humour, all laugh now>.

	- Tel