[過去ﾛｸﾞ] TypeScript part3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
698(1): デフォルトの名無しさん [sage] 2020/12/18(金) 05:11:45 ID:7UB7snzp(1/6) AAS
ブラウザ使っててよく Webページ が固まることがあるから、ちゃんとUIスレッド以外で処理しろよとよく思ってたが
JavaScript 自体がシングルスレッドだったのね
WebWoker とかいうのもあるみたいだが、MDN見るに、
言語側でがっつり管理するからスレッドセーフあんまり考慮しなくてもいいみたいだし、これは楽でいいわ
Java やってて、クリティカルセクションの処理が一番嫌いだった
デッドロックの原因探すの大変すぎた
700: デフォルトの名無しさん [sage] 2020/12/18(金) 07:23:19 ID:7UB7snzp(2/6) AAS
まぁでも、
JavaScript のソースコード内に書いたものが全部同じスレッドで走ってる
ってだけで、setTimeout とかの実装内では普通に別スレッド走ってるのか。
そりゃそうだよな、そうしないと非同期処理なんてどうあがいても不可能だものね。
704: デフォルトの名無しさん [sage] 2020/12/18(金) 13:13:24 ID:7UB7snzp(3/6) AAS
最近ないように思うけど、１つのページがブラウザ全体をストールさせることが多かったのよ
そんでブラウザを起動し直さなければいけない
その原因が、JS のスレッドと ブラウザのレンダリングスレッド（UIスレッド）が同じスレッドを共有してることにある
DOM 書き換えてる最中に レンダリングされちゃうと、ページレイアウトがぐちゃぐちゃになるから、全部同じスレッドで処理してるんだけど、
JSの処理でUIが固まるのを防ぐには、JS の DOM 書き換え「以外」の操作を別スレッドでやって、レンダリングスレッドと同期処理すればいい
（Java の synchronize とかの要領）
DOM 自体が レンダリングスレッドに属してるのは、しょうがないと思う
昔、マルチスレッドで動作する UI ライブラリ の多くがデッドロックその他のバグでどうにもならなくなって廃棄された（Java でいう AWT）
ということで、UI が固まるのにはスレッドは関係あると思うのよ
まぁ書き方が悪かったのかもしれんが
あと、JS がシングルスレッドなのはとても良いことだと思ってるからね、自分は
マルチスレッド化したら、どのみち同期化処理に失敗して、デッドロックで今よりも固まること多くなるだろうから
参考にした：
外部ﾘﾝｸ:stackoverflow.com
705: デフォルトの名無しさん [sage] 2020/12/18(金) 13:18:46 ID:7UB7snzp(4/6) AAS
JS で重めの処理をしたりバグがあっても、レンダリングスレッドと分離されてれば、
少なくとも UIが固まることはないということね（デッドロックがなければ）
あと、上で最初に書いた、ブラウザ全体が固まるって話は語弊あったかもしれない
ブラウザの各タブのレンダリングスレッドと、ブラウザ全体のUIスレッドは、多分分けられてるんだよね？
後でちゃんと調べます
707: デフォルトの名無しさん [sage] 2020/12/18(金) 16:42:31 ID:7UB7snzp(5/6) AAS
外部ﾘﾝｸ:gimhana-ds.medium.com
ブラウザのスレッドの話ココに載ってた
いろいろとたどってって疲れたので、全部は見てない
Chrome が Tab ごとにプロセスで、Firefox が Tab にマルチスレッド
Firefox もいっぱいプロセス作ってるけどね、ちゃんと読んだ人教えて
708: デフォルトの名無しさん [sage] 2020/12/18(金) 16:44:48 ID:7UB7snzp(6/6) AAS
「Firefox が Tab ごとにスレッド」って書きたかった
そのスレッドも Main Thread = UI Thread （DOM 操作と JS 実行）が１個って意味で、
Raster Thread とか、Composer Thread とか多分他にもいろいろスレッド作る
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s