SASADA Koichi <ko1 / atdot.net> wrote:
> On 2017/01/31 18:18, Eric Wong wrote:
> > SASADA Koichi <ko1 / atdot.net> wrote:
> >> Eric:
> >>
> >> I'm not sure about implementation of IO.copy_stream but do you need to
> >> add this flag for *all* of T_STRING?  We need to care this flag if we
> >> want to manipulate strings.
> > 
> > This flag is only set for klass==0, now.  It is safe to use
> > for all klass (at least all tests+rubyspec pass),
> > but I limited it to klass==0 to avoid triggering CoW.
> > 
> > I don't think using this flag (FL_USER6) imposes new burdens for
> > anybody.
> 
> My question is "are there any other way for this purpose?". Because of
> using flags, I think we "all of string.c hacker" should know this flag.

I tried to find a better solution, but could not think of one.

I hoped someone else (mainly, nobu) could think of a better way,
but nobu seems OK with trying my patch.

> My another question is, is this flag technique is valuable to pay this
> effort for all string.c hackers?

I kept all changes to internal API and mainly changed existing
functions + macros.  Learning new functions is completely optional.

> Maybe I need to read it... (Honestly, I can't read it enough)

Please read it and bring up any concerns you may have :)
I will be happy to help find better solution.  Thank you.



Sidenote: a historical reference about my view of threads...

In 1.9.[01] days, I had major doubts about native threads.
days because I liked predictability of green threads in 1.8.

By the time 1.9.[23] came out, I started to like native thread
for certain things: (slow) filesystem I/O, blocking accept4(),
fcntl locking, flock, libmysqlclient API, etc.

Now, I again have doubts about our decision to use 1:1 native
threads.  Expensive changes like r34847 (the reason for this
change), timer thread, big stack sizes, along with associated
fallout/fixups like this change make 1:1 threads seem like the
wrong decision in retrospect.

So in the future, maybe we should take advantage of native
threads in C API only for using blocking APIs from OS and
3rd-party libraries; and hide that from normal users.

Then, make: Thread == (Fiber + auto-preempt), like 1.8.
And then do good IPC + MVM :)

Anyways, just wanted to let you know my perspective changed
over the years and perhaps that explains why I still use
single-threaded Perl5 on new projects :)

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>