>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
green threads).

           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.