Multi-threading the interpreter
zss at ZenSpider.com
Mon Nov 16 18:14:42 UTC 1998
>I'm agreeing with you. But that problem is a design of concurrency access
>in gerneral. Back when I did a lot of the architecture
>work on a VSE project that had 38 to 40 forked processes running at once,
>we had to account for this possibility even though the
>Smalltalk/V VM was not multi-threaded. I remember getting bitten by the
>#reverse method where the size changed while walking the
>collection. The lesson I learned was to never assume that existing
>Smalltalk frameworks work well in a concurent environment and
>that what you might htink is an atomic operation isn't.
Gemstone's RC classes might be a good thing to study in this regard... Also
java has a bit to offer as well. (and by extension, Gemstone/J would be
worth looking at)...
Also, isn't the whole single-threaded vs multi-threaded issue parallel to
java's green vs native threads??? If so, then if we followed that design we
could transition between the two w/o the programmer taking account for it
(for the most part--there were several gotcha's in Sun's implimentation of
Ryan Davis -=- Zen Spider Software
-=- mailto:zss at ZenSpider.com -=- http://www.ZenSpider.com/ -=-
I know that you believe you understand what you think I said but,
I'm not sure you realize that what you heard is not what I meant.
More information about the Squeak-dev