[squeak-dev] Re: n-core Smalltalk at work [Re: Hydra now can do mitosis]

Philippe Marschall philippe.marschall at gmail.com
Sun Feb 22 17:18:20 UTC 2009


2009/2/22 Klaus D. Witzel <klaus.witzel at cobss.com>:
> On Sun, 22 Feb 2009 16:52:58 +0100, Philippe Marschall wrote:
>
>> 2009/2/22 Klaus D. Witzel :
>>>
>>> On Sun, 22 Feb 2009 14:36:30 +0100, Igor Stasenko wrote:
>>>
>>>> Update.
>>>> you can download binaries from here
>>>>
>>>>
>>>> ftp://ftp.squeak.org/HydraVM/latest_builds/win32/HydraVM-bin-22.02.2009.zip
>>>>
>>>
>>> Let me add 2-3 bits: ...
>
> [...]
>>>
>>> You Smalltalkers may have other Smalltalk processes that you want to run
>>> in
>>> parallel on their own native thread; let us know how we can help you with
>>> that.
>>
>> Well I have this web framework thingy where each http connection runs
>> in it's own process. Request processing is quite fast, sometimes below
>> a millisecond. There is potentially a lot sharing going on between
>> those connections for configuration, sessions, continuations and
>> stuff.
>
> Yeah we thought about that, after exchanging some Qs+As with Lukas (and/or
> you?) during last Camp Smalltalk, for the general case for Hydra.
>
> Several things are competing for attention/resolution/prototypical work:
>
> 1) some [accepted] Socket (and its OS dependent bits) can "belong" only to
> one native thread (= independent .image) in Hydra. Is this compatible with
> your web framework's requirements.
>
> 2) it must be possible for one native thread to accept a Socket, for another
> one to read/write it and get rid of it (and of its OS dependent bits). This
> is not a problem for us at the Smalltalk language/heap level but, until now
> I did't find an OS guy who said "this works, with guarantee, on these XYZ
> platforms".

That and 1) do not necessarily need to happen. You could imagine one
image/native thread doing all the socket IO and handing the actual
work to other images/native threads.

> 3) when your web framework+app depends on a database "whatsoever", how is
> this to be shared (if sharing is really needed) between multiple native
> threads.

Yepp, if you interpret database in a more general sense (a bunch of
objects). There is also the question of how coordination happens
between multiple images especially on this shared data.

Cheers
Philippe



More information about the Squeak-dev mailing list