On 2010-Oct-13, at 11:58, Eliot Miranda wrote:

> 
> 
> On Wed, Oct 13, 2010 at 11:53 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> 2010/10/13 Levente Uzonyi <leves at elte.hu>:
> > On Tue, 12 Oct 2010, Igor Stasenko wrote:
> >
> 
[snip]
> 
> i don't like the code, which assuming that scheduling works in some
> specific way,
> or some code can't be interrupted in the middle.
> 
[snip]

> For same reason, there is no any guarantees from VM side that three
> assignments in a row will be
> atomic: storing pointer could trigger a root check, and if roots table
> is full, it could trigger GC,
> and after GC, there is a finalization semaphore, which could switch an
> active process immediately.
> 
> VM is evolving and subject to change. Having a clear rule which
> guarantees a specific behavior is far more
> beneficial comparing to intimate knowledge about how VM works (now).
> 
> +1.  I think there's general agreement on this.  All this uninterruptibiity goes out of the window (as does Processor activeProcess) as soon as anyone does a truly concurrent implementation.

+1 here too.  This was sort of in the back of my mind when I mentioned that all current HW has a CAS instruction or equivalent.  If the VM makes use of a the HW CAS instruction as the heart of the bytecode, you have future-proofed at least the one bytecode :).

[snip]

Regards,

--
Tom Rushworth