[Cryptography Team] FW: yet another smallest snapshot, and a visualization

[Ron Teitelbaum]

Paul,

I saw this post on squeak-dev.  When looking at the software I noticed that
it has built in support for ASN.1.  I'm not sure if it will be of any help
to what you are working on but I thought I'd point it out to you, if you
want to take a look at their code.

Ron

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Todd
Blanchard
Sent: Saturday, January 21, 2006 10:02 PM
To: The general-purpose Squeak developers list
Subject: Re: yet another smallest snapshot, and a visualization

I just got an introduction to erlang, this sounds kind of like that.   
Lots of interesting concepts worthy of theft in that language.


On Jan 21, 2006, at 10:56 AM, Colin Putney wrote:

>
> On Jan 21, 2006, at 12:28 AM, tim Rowledge wrote:
>
>>> This is interesting to me. Do you think it is feasable to take  
>>> out all of the process management from the VM and put it back in,  
>>> say, via a plugin?
>> I think so. No need for the special objects array or Processor  
>> instance if the saved context oop is either explicitly saved in  
>> the image header or simply put somewhere by convention (like nil  
>> true and false used to be) which would be trivial with Craig's  
>> version of the tracer. You could start a copy of a VM for each  
>> process and terminate it when the process concludes. This VM would  
>> need no process handling stuff such as wakeHighestPriority but  
>> might need some semaphore stuff?
>> Debugging might be fun. Coordinating threads would have the  
>> potential for getting to be as awful as java. On the other hand it  
>> wold be an interesting way of making completely separated cells of  
>> objects each running their own process and having to communicate  
>> only via proper interfaces instead of messing in a global object  
>> soup. All sorts of fun possibilities if one has the tim and funding
>
> Indeed. The end result would be message-passing concurrency, rather  
> than shared-state concurrency. Each VM instance would be a Vat/ 
> Island/Task and you'd have distant object references for sending  
> messages between them. VM instances could also be on a separate  
> thread, in a separate process or on a separate machine, depending  
> on what kind of performance characteristics you were looking for,  
> pretty much transparently. Beautiful.
>