This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: continuation and multi-threading
Jost Boekemeier <jostobfe@calvados.zrz.tu-berlin.de> writes:
> > > I really think (also regarding your other message) you should try to
> > > understand the issue before posting.
>
> me> I can't see anything in Mikael's post that could justify such
> me> hostility.
>
> Umm, where and why do you see any hostility in the above quote? I meant
> what I said.
>
> I really think that it is a good idea to examine an object before
> speculating how it might work. I've made the same mistake several times
> in the past, so I know what I am talking about. :)
I was not objecting to the substance of your message, just the tone.
and, as I said, it's quite possible that my perception (of rudeness)
was incorrect -- we both happen to be non-native English speakers, so
such unfortunate misunderstandings are bound to happen. if so, sorry.
> Yes, I am quite sure that it is easy to implement cheap
> continuations for his VM without slowing down the evaluator too much,
> instead of building ourselfs into a corner with stack copying.
I haven't looked at Keisuke's VM either, so perhaps I'm wrong, but I'm
not very afraid of any "building ourselves into a corner" wrt
continuations -- it's just a function of the way the VM manages Scheme
activation records (aka frames). I don't see why it should influence
the VM _interface_ in any way.
> I think that pushing his VM towards stack copying is a bad idea if we
> haven't tried other possibilities. Someone has said that "We
> don't require that a thread can call a continuation created from a
> different thread." This might be true, but at least SRFI 18
> requires it:
>
> A thread can also call a continuation captured by another thread as
> long as the call and the continuation are not in the scope of an
> dynamic-wind.
as a matter of fact, I fully agree with you here. if the evaluator
doesn't need the C stack, it might just as well implement
fast continuations. SRFI-18 support would indeed be very nice.
> I don't think that it's a problem that ordinary users may get a bad or
> wrong impression about guile from this list. If it is, why not put a
> sign at the entry that says "public works".
interesting possibility ;).
--
Hit the philistines three times over the head with the Elisp reference manual.
-- Michael A. Petonic