Hello!
On Tue 02 Sep 2008 21:56, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> SCM
>> scm_m_let (SCM expr, SCM env)
>> ...
>> /* plain let */
>> SCM rvariables;
>> SCM inits;
>> transform_bindings (bindings, expr, &rvariables, &inits);
>>
>> {
>> const SCM new_body = m_body (SCM_IM_LET, SCM_CDR (cdr_expr));
>> const SCM new_tail = scm_cons2 (rvariables, inits, new_body);
>> SCM_SETCAR (expr, SCM_IM_LET);
>> // ****!!!
>> SCM_SETCDR (expr, new_tail);
>>
>> What happens if another thread tries to evaluate expr at the place marked
>> ****!!! ?
>>
>> At the very least, we should have an atomic SCM_SETCELL() which overwrites
>> car and
>> cdr atomically.
>
> Anyone? Does anyone still understand how the evaluator works?
It sounds to me like you're right; and it sounds very similar to the
lookup car race. Anything that mutates the code structure in place
(memoized or not) needs to be atomic; we can rely on all threads
reaching the same conclusion, as in the lookup car race, but the actual
mutation should happen atomically.
> (if not, let's move
> to the VM earlier than later.)
I think we have much more experience with the bugs of the interpreter
than the bugs of the vm ;-)
Seriously, it is good to have both -- for bug checking, sanity testing,
and avoiding circularity. Otherwise we have to start distributing .go
files. Guile's interpreter is fantastic, and there's no reason to throw
it out -- although we may want to make it simpler, and push much of the
optimization efforts into the vm.
Andy
--
http://wingolog.org/
