On Jul 6, 2008, at 11:41 AM, Peter William Lount wrote:

> Hi,
>
> Oh, clearly I misunderstood about Hydra. I thought it could handle  
> more than one native thread per image in memory.

Nope, only one.

> My mistake if it can't. Unfortunately I've not yet had time to take  
> a look at hydro up close.
>
> The one native thread per image model is an ok idea idea however it  
> fails to cover many situations for which multiple threads provides  
> the better or even simpler solution.
>
> Besides as soon as you have two threads of either kind you  
> essentially have many of the same issues and the same level of  
> complexity of issues involved with regards to concurrency and data  
> coherency of objects within the image. As soon as you have two or  
> more images you have data coherency issues across those images.  
> These problems don't magically go away by limiting the native  
> threads per image to one.

That's true.  However, it provides a simple way to conceptualize which  
threads are accessing which memory; you can then design your  
application accordingly.  This simple model doesn't exist with  
multiple-threads-per-image (not that *something* couldn't be designed  
to play the same role, but it's not immediately clear to me how that  
would work).

Best,
Josh


>
>
> All systems regardless of design have scalability issues. It's the  
> nature of the beast.
>
> Erlang certainly has a lot going for it's model even though it's not  
> fully message based nor object based.
>
> Thinking to see further than simplistic solutions and doing the hard  
> work to get there are both important.
>
> All the best,
>
> Peter
>
>
>