Hi,

At Fri, 20 Feb 2004 22:49:52 +0900,
Sean Russell wrote in [ruby-talk:93246]:
> The new code uses IConv, which is now a standard part of Ruby.  UConv
> is, AFAIK, obsolete, in addition to requiring a separate download and
> install.

I don't think UConv is obsolete, and as for IConv, which is a
standard part certainly, also needs another library, libiconv
which may not be available on all platform.

> The old code handled encodings via aliasing a method to the
> decoding/encoding methods.  This was not thread-safe fixable except
> via Method objects or eval(), both of which are way too slow to be
> used in the encoding algorithm, which is a frequently called bit of
> code.

I'm not sure which versions you mean by "old code" and "new
code".  Do you mean the code older than imported to ruby CVS
repository?

> Each encoding required two files.  Yuck.

Sorry, what two files?

> The new encoding code is pretty ugly, too, and I may give up and drop
> the mixin metaphor.  However, I need to test the code in a threaded
> environment.  I tried to use the singleton pattern when I implemented
> the new code, and I believe that it is thread-safe.  It is not very
> efficient to set an encoding, but I doubt that this will have much
> overall impact on program execution; much more time will be spent in
> parsing, which is what I optimized the encoding support for.

But current encoding code also doesn't seem thread-safe.  What
happens if the context switches between setting the class
variable and instance_eval?

-- 
Nobu Nakada