Re: gh_enter reconsidered

[Tel <telford@eng.uts.edu.au>]

> Tel> All we need is a void gh_enter() that is allowed to return, a bar
> Tel> that prevents any eval outside of the sphere of gh_enter() and
> Tel> then the user can make use of scripting for side effects if they
> Tel> want to, while popping in and out of the SCM sphere whenever they
> Tel> need to.  We already have restrictions on storing SCM values in
> Tel> global variables and since global variables would be the only way
> Tel> to pass values out when gh_enter() returns void, no additional
> Tel> restrictions have been incurred.
> 
> It seems to me that this isn't really any better than the current
> mechanism, since either a) you need a single entry point into scheme
> (i.e. all the guile code is called through a single piece of
> functionality) or b) you're going to be passing functions to gh_enter
> left and right, and gh_enter will have to be able to be called within
> a gh_enter context (confusing, IMO).  

Admittedly, it's not to be encouraged to call gh_enter() inside its
own context but it shouldn't actually hurt either. You have to give
users some credit for a bit of high level software design but not clobber
them if they get it wrong.

The stack top for the scan is going to be a C global variable, this is
the current situation and no one has suggested trying anything different.

One method is to say: outside the scheme context, the global is zero,
inside the scheme context it has a non-zero value.

gh_enter() needs access to the global anyhow so if the value is non-zero
it doesn't change it. The top-level gh_enter() zeros the stack top global
as it leaves.

> It's also a bit of overhead to make sure you're "inside" a gh_enter
> context all the time.

OK, there's probably a bit of overhead in checking a global
variable but most users are not going to pop in and out of context all the
time. Additional checking for a valid stack top can be done inside the
evaluator but done by an assert of some sort that can be compiled out if
you want more speed and less debugging.

This makes the system no different for people that never leave gh_enter()
(which is all of us at the moment) and will at least be usable for people
who have no control over their stack or their main() (like Microsoft foundation
class users -- shudder).

An alternative method is to have gh_enter() always calculate a new stack top
but only replace the value of the global if the new value is higher on the
stack than the existing value (allowing for stack growth direction :-).
Under this method, when gh_enter() leaves, it does not alter the global stack
top variable.

Thus, the known stack top slowly moves towards the absolute stack top.
There would be some cases where something higher level than guile may be
playing tom foolery with reallocating stacks (e.g. you are running inside
someone's thread system) where this would break but it would at least be as
good as the current system, or as good as any system specific hack that finds
an absolute stack top by magic.

BTW: I am not trying to encourage flipping in and out of the scheme context
with great abandon. An application build to use guile from the ground up should
call gh_enter() once and stay in there. The thing is that many applications
will be retrofits and compatibility efforts, my suggestion doesn't take
anything away from users who want to stick with what they have right now.

	- Tel