2009/2/22 Klaus D. Witzel klaus.witzel@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:
- 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.
- 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.
- 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