Erlang (was: Re: Generics)

Eric Merritt cyberlync at yahoo.com
Mon Nov 10 20:43:33 UTC 2003


> There is a paper in the recent OOPSLA proceedings
> about a pattern-matching 
> version of Java. This could be done easily in Squeak
> as well.
> 
>
http://www.cs.washington.edu/research/projects/cecil/www/pubs/hydroj.html

I will take a look. Thanks.
 
> 
> Why not? If you subclass ProtoObject for the
> (publicly visible) message 
> receivers and make it impossible to get to the
> actual active objects you've 
> done about the same thing.

 Hmm, this is probably something to take a look at. I
have a little simulation I am working on that requires
tens of thousands of concurrent processes (well there
is probably another way to do it but I like processes
conceptually). 

> 
> >  2) Cheap preemptive multi-threading.
> >    From what I understand from previous
> discussions on
> > this list, this would be a major undertaking
> requiring
> > big changes to the VM and massive refactoring of
> > existing code. That being the case I don't see
> this
> > happening anytime soon.
> 
> What do you mean? We *have* cheap preemptive
> multi-threading in Squeak.
> Am I missing something?

 I was under the impression that we had cheap
cooperative threading. There is quite a difference
between the two. 

----
In cooperative models, once a thread is given control
it continues to run until it explicitly yields control
or it blocks. In a preemptive model, the virtual
machine is allowed to step in and hand control from
one thread to another at any time. Both models have
their advantages and disadvantages.
---

 I pulled the above description off the web, not sure
where I originally got it, but its a good description.


As regards cheap, from what I understand squeak has no
problem with tens of thousands of concurrent
processes. However, if we are comparing cheapness with
erlang it would have to run nicely with hundreds of
thousands of concurrent processes.

 
> >  3) Transparent non-blocking IO.
> >   All IO in erlang is non-blocking (this may not
> be
> > the case for linked in drivers). Basically this is
> > completely transparent to the erlang programmer.
> The
> > system takes care of starting and stooping a
> process
> > that can't read or write data. I know so little
> about
> > the Squeak IO system that I can't really comment
> on
> > the relevance of this to Squeak.
> 
> I don't understand. If you stop a process that can't
> read data, you've blocked 
> it. How is this "non-blocking"?

 Thats true, but only that one thread is blocked. All
the other threads continue to function. If you are
using system threads this isn't a big deal at all,
however, all threads in erlang (and squeak for that
matter) are green threads. This basically means that
threading is in the vm and does not use native OS
threads. In this case, not blocking the vm is very
important.
 


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree



More information about the Squeak-dev mailing list