Re: Can the Guile library be reentrant

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

> > The problem comes up when porting to that obscure operating system:
> > Windows.  Windows (at least under the MFC package) requires the main
> > program to *RETURN* to the operating system, and not sit in an event loop.
> > All interaction then occurs with messages that are sent to the application.
> > I know that Tk cannot be run under MFC on Windows (it can run as a non-MFC
> > application).  I suspect that GTK is the same.
> 
> Okay.  So in other words, you have no control over the `main'
> function: Windows calls your initialization function, which must
> return before the world begins to operate.  Is that what you mean?

Yeah, that's the way they do it. I haven't made big steps into porting
to MS-Windows but I was intending to use plain win32 API calls which avoid
a lot of unnecessary fat and probably give a more reliable result
(admittedly with less frills).

It also means that the result will be compilable under cygwin32 and other
such compilers rather than just Microsoft compilers.

> Well, this isn't necessarily a group of Linux folks.  I'm running
> Ultrix and Solaris at the moment.  :(  I haven't seen anyone be rude
> about that issue on this list, which is great.

thbthbthbthb windows
thbthbthbthb microsoft

Having cleared the air, more portability is better than less portability.

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

Some event driven stuff uses a (wait-token, fetch-token, execute-token)
loop where all events are tokenised and there are a lot of big switch
statements. X does this, the old Amiga API did this and win32 does this.
It is quite easy to keep control of a process with this method.

Some event driven stuff uses hooks and callbacks where you pass away function
pointers and those functions get called later from some other place
(you know not where) and when this happens you have no guarantee at all
of the stack behaviour (it may not even be the same stack, though in
practice I guess it usually is). This is basically (how to say this?)
a butt-ugly form of programming but then again, scanning out the calling
stack for anything that looks vaguely like data worth keeping is not
real pretty either. What I am saying is that with callback pointers
being called from the other side of a black-box API, no single setting
of a stack-top is a guaranteed solution.

May i suggest that there is a gh_init_no_stack() function that sets
up all the interpreter data structures in their global form but does
NOT leave anything on the stack, nor make any notes regarding stack
position (and yes this means that it does not set any continuations or
exceptions either). Then there is gh_minor_enter()
that just sets the last few things (like marking off the stack,
establishing some exception handler for errors) and then executes
some scheme code.

The limitation of this approach is that you have to guarantee that
no SCM objects are stored on the stack at a lower level than the
gh_minor_enter(). Storing them in global places like defined scheme
variables is still OK. Using the stack within smob functions is also
OK because these will always be called under gh_minor_enter().

	- Tel