Re: gh_enter reconsidered

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

> I've been looking at the possibility of adding Guile scripting plugins
> for various Gnome apps, like gnumeric (which already has python and
> the beginnings of perl support). It looks like in many cases, gh_enter
> is a major problem - these apps load plugins as dynamicly linked
> modules, not separate processes, thus making Guile's desire to own
> main a big hindrance which cannot be circumvented. I know many
> technical issues came up last time this was discussed, but this is
> becoming a problem in practice so I hope we can reconsider it.

Definitely.  Maybe I was more stubborn in public than I was in my own
mind, but I thought I'd said so...  it's been on my to-do list,
anyway.


There's nothing too difficult about it; here is the only complication:

Finding the stack base is a very system-specific job, so someone needs
to get access to ten different operating systems and produce a
function that works on all of them.  The result should be autoconf
test which tells you how to find the stack bottom on this system, and
some C code which uses the outcome of that test.

I'll bet the actual code executed on any given system will be one or
two lines.  But the function will be chock full of #ifdefs, to use
whatever mechanism autoconf finds.

First approaches: the environment variables and argv strings live
above the stack base in many implementations. 

Desperation: if you know the architecture and the ABI is decent, walk
the stack frames.

When we start supporting more thread packages, that'll add another
variable, but at the moment, this shouldn't be an issue.