Re: mt question/problem

Vladimir Tzankov writes:

 > Actually it worked (almost) the way you describe until 2009-10-25 when
 > I changed it in cvs. Now rethinking it - looks I wrongly removed it.
 > Every special declaration should allocate per thread value cell for
 > the symbol (if it does not have already).
I think above means (but I want to verify) that you plan to change
things so that all bindings of special vars are -per-thread.
Let me know when you think it's done and I'll try removing the defvar
I had to add.

 > > So far I'm having trouble seeing when/why it's useful to do that
 > > evaluation in the new thread.
 > Whenever (current-thread) value or some mutex ownership involved in
 > evaluation is important.
Why not 
 (mt:make-thread (lambda () (let ((*th* (mt:current-thread))) ...)))
Or for that matter,
 (mt:make-thread (lambda () (let ((*read-base* *read-base*)) ...)))

These seem related to this:
 > (defun new-thread (function &rest args)
 >    (mt:make-thread (lambda () (apply function args))))
in that it feels to me like you're going out of your way (adding
initial bindings arg) to make it easy to do things that I'll rarely
want to do while failing to make it easy to do things that I'll
normally want to do.  I'd expect it to be relatively rare that
programs even mention things in *default-special-bindings*, let alone
change them or rely on having different values in different threads,
whereas one will almost always want to pass arguments to the functions