LOGO-L> Re: Logo with parallel processes vs. ToonTalk

["Ken Kahn" <KenKahn@ToonTalk.com>]

Brian Harvey wrote in message <73uosj$e1s$1@agate.berkeley.edu>...
>If the execution is truly parallel, then of course that state won't wait
>around as long.  But unless you're telling me that a thread has *no* state
>information associated with it, I'm afraid I still don't see where the
>saving of memory comes in.
>
>Now, perhaps you are using a really bad memory management system in which
>a large chunk of physical memory has to be allocated for a stack, whether
>or not it's used.  But that isn't the fault of stacks, or Logo, or
>composition of functions!
>
Implementation arguments are slippery. You seem to be arguing what is
possible and I'm arguing what is current practice. When Java died because I
had a few hundred threads, I checked news groups and talked to experts who
said that is what you should expect. Now maybe the Java implementors didn't
do a very good job (and I tried it on more than one Java implementation).
But you really can have tens of thousands of threads or processes in
ToonTalk. Millions if there wasn't the overhead of the ToonTalk programming
environment (i.e. if ToonTalk supported invisible houses that couldn't be
entered).

I believe the Java implementation of threads is good and that within their
framework it would be too expensive to support thousands of threads. I refer
to Java only because I am more familiar with it. I believe that the cost of
threads is high in all mainstream languages that have added threads.

>
>or whatever.  What you are arguing is that the ability to do procedure
>calls inevitably leads to storage loss, and I still don't see it.

"Inevitably" might be too strong a word. I'm arguing it does in practice.

Best,

-ken kahn (www.toontalk.com)


---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.