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>