< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事（スレッド移動）
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事（前）
<:同じ返事先を持つ記事（後）
---:分割してスレッド表示、再表示
| :分割して（縦）スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
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>