------art_1094_3713911.1130207734886
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>
>
> > I assume that you don't expect multiple threads to access the same
> object.
> > It is generally assumed that you should guard your objects. E.g. noone
> > expects a string object to handle #size properly while another thread
> calls
> > #slice!. But you are probably referring to something else...?
>
> If it is guraded outside, thread-safeness in a method is not
> important, or even redundant. In general, the word
> "immediately" makes no sense with multi-threading. Atomicity
> is important.


Agreed. I guess my definition of 'thread safe' is different than yours.
Calling instance_eval (of all methods) on an object in a multithreaded
environment without locking an object first is...well...someone else's
problem. I'd have to look into it more, but I think much of ruby core is not
'thread safe' under this definition. Am I missing something?

>
> I know, and don't intend to offend you at all. Just a nitpick.



No offense taken :) I was just hoping for comments on the
instance_eval/instance_exec relationship, the need for block arguments when
calling instance_eval, and C implementation ideas. So far, most of the
attention has been on the quick hack I submitted, which I didn't intend to
be the focus.

Dan

------art_1094_3713911.1130207734886--