Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!bloom-beacon.mit.edu!world!edwards
From: edwards@world.std.com (Jonathan Edwards)
Subject: Multithreading & multiprocessing
Message-ID: <D1ypys.8G5@world.std.com>
Organization: IntraNet, Inc.
Date: Fri, 6 Jan 1995 02:37:40 GMT
Lines: 43

Dylan, as defined so far, has no support for multithreading.
The FAQ mentions that this might be supported in a library.
That worries me, as most library implementations of threads are fake.
I very much hope this issue is not being ignored, as it would be a
competitive disadvantage against C++ (and also kill Dylan's usefullness
to me, which is frankly the real reason for this post).

Lets be clear what REAL multithreading means: two threads can execute within
the same program/address space in PARALLEL on a multiprocessor machine.
To the best of my knowledge, no commerical dynamic language (Smalltalk or Lisp)
currently has this capability.

I don't know enough about Dylan implementation to know how problematic this
is. C++ needs such minimal runtime support that it is pretty easy - just put
semaphores on malloc et. al. and fix errno. But Dylan will surely require
fairly fancy method dispatch and garbage collection support. I suspect that 
if multithreading is not established as a requirement from the beginning it 
will be very hard to retrofit. And given that the MAC OS is particularly 
archaic in this  regard, the Apple Dylan folks may not feel it is a pressing 
need.

So, can anyone say that Dylan will in fact support true multithreading and
multiprocessing? Or that it will in fact be easy to make the Dylan runtime
thread-safe, and I am needlessly worrying?

I hope this is taken constructively: I really want Dylan to succeed.
C++ is not just a bad language: it is EVIL.












-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020
One Gateway Center				FAX: 617-527-6779
