This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]