Hi,

Jason Johnson wrote:
> On 10/25/07, Peter William Lount <peter at smalltalk.org> wrote:
>   
>>  The "process-based model of concurrency" - as used in Erlang - is but one
>> approach in a wide range of techniques that provide solutions for
>> concurrency.
>>     
>
> A wide range?  I'm aware of variations of only 3 ideas.

What are they?


>   Could you expand on "wide range"?
>   

Sure, one only has to search the internet for "concurrency" and one sees 
a wide range of problems and potential solutions. Look at the Little 
Book of Semaphores for a breathtaking look at a few of the many possible 
solutions to various problems. Open your eyes to the wider horizon.



>   
>> It doesn't solve every problem in concurrency - I don't even
>> think that they claim that for it. If they do please show us where.
>>     
>
> Would you please stop making a statement that I obviously didn't say
> (you even quoted me!) and then attacking that statement you made as
> though it were mine?  I find that quite disingenuous.
>   

I never said you stated that explicitly - I'd have to check all your 
postings to find that out. It's implied by what you are saying in many 
of your postings. At least that is the impression that I'm getting from 
your writing. You've certainly not acknowledged the opposite.


>>  Further the example of the one million object graph being processed by
>> 10,000 compute nodes processing the problem is that you don't know in
>> advance how to slice up the data. If you can know in advance how to slice up
>> the data then you've simplified and possibly optimized the problem solving.
>> However, that's the problem, slicing up real world data object sets that are
>> highly interconnected with each other and processing them in parallel.
>> That's an example of a more general case. There are other examples that
>> won't compute with the slice em and dice em approach using the process-based
>> model of concurrency.
>>     
>
> Do you have any real-world cases where it's a problem?  I'm not
> interested in solving theoretical problems that never come up in
> actual practice.


Yes, the example I gave is a good summary of real world problems that 
actually occur (and that I'm working to solve for one project). It's not 
just theory, it's a harsh reality.



Cheers,

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071025/21c03194/attachment.htm