Re: stack checking and threads

[Aleksandar Bakic <bakicale@cps.msu.edu>]

> 
> Mikael Djurfeldt <mdj@nada.kth.se> writes:
> 
> > I don't understand the question.  What does "[stack checking] work
> > with C/C++ (OS) threads" mean?
> 
> I see now that this sounds a bit petulant.  That was not my
> intention.  I'm honestly not quite sure what your asking.
> 

That is fine, don't worry :)

> > Q: Does Guile work with OS threads?
> >
> > A: No.  Currently, Guile only works with its own cooperative threads.
> 
> But, as long as you initialize and access Guile from the same thread,
> no problems will occur.

Yes, but what if I access GUILE from a thread different from the one
in which GUILE was initialized? `eval' will report stack overflow as
soon as it checks the stack, because it is not the same stack GUILE
was initialized with.

> 
> > Q: Can Guile be extended to work with OS threads?
> > 
> > A: Yes, but it is a fair amount of work to do so.
> 
> And still, new threads will have to be created with Guile primitives
> for this to work.
> 

This is what I meant by the possible extention. I didn't mean the
GUILE threads that can be created with Scheme primitives, but threads
in user C/C++ code, independent of whatever thread support is
available in GUILE. In particular, I thought there could be a GUILE
call (something similar to the one that disables interrupts) during
evaluation invoked from a thread different from the one in which GUILE
was initialized.

> /mdj
> 

Aleksandar
-- 
Aleksandar Bakic, Comp.Sci. graduate student at Michigan State University
e-mail: bakicale@cps.msu.edu