Re: [討論] javascript是共時、多執行緒嗎?
就我所知 目前的borwser對於每一段script
都是先parse (js特殊的hoist現象就是這裡發生的)
之後執行top-level應該執行的東西(load完後馬上要執行的)
接著開始listen event
每一段script block都是一起parse
然後執行
接著繼續下面的HTML Parse (script blocking就是這樣產生的 所以要放下面)
在這個parse過程 他會調整你的code
像是一個context裡的變數會幫你拿到最上面幫你宣告好之類的(hoist)
在之前的例子裡 一個iframe只有一行code 我想有99.99%的機率是ABCD
不管哪個browser應該都是這樣
第一個iframe parse完就開始 run了
第二個iframe說甚麼也不會比較快 (CDAB)
然後只有兩個log間也是不太可能被插隊 (ACDB)(ACDB)..etc
alert(confirm prompt等等)的例子為甚麼混淆視聽
是因為這和browser本身UI的實作有關 而和他對Javascript的實作關聯不大
(像是跑出來時 不接受你按按鍵 這是browser的UI問題 而不是js問題)
在我的FF中 有看到alert A一閃 然後被C蓋住
我想他就是會讓後來出現的alert蓋住前面
CD按完就可以看到下面的A了 A按了當然就跑出接下來的B
而IE的例子中
好像不可以同時有兩個alert
我甚至不知道他有沒有multi-thread
因為第一個alert A出現之後
如果有multi-thread 緊接著alert C應該也蠢蠢欲動才是
但也有可能 他的alert出現時 整個HTML parse thread也停下來了
實驗是在你alert後面放html 按下去前看不到
(但rende和parse又是不一樣的東西 時間也不會一樣 所以這無法證明)
所以A按完後 為甚麼是B而不是C 這我目前就不知道了
只能說和他的alert實作有關
所以用alert去看這種thread的問題 我覺得是會有很多誤導的
※ 引述《tyx (?????????????????)》之銘言：
: 在同一個 page 裡 只有一個 thread 在執行
: 不管有幾個 iframe 都一樣 (但 Opera 不是 推文有連結)
: 那為何有不同的行為
: 我以 senser 的範例作說明
: 1. FireFox
: 當 FF 執行 $('ifa').src = 'javascript:alert("A");alert("B")'; 時
: 會先 parse 這段 javascript 但並不會立刻執行此 js
: 而是產生一個 '要執行此 js 的 event'（暫時稱為 event1） 在 event queue 裡
: 之後執行下一行 $('ifb').src = ... 並產生 event2
: 然後 thread 回去 event queue 取到 event1 並執行 alert("A")
: 此時會看到 alert("A") 的 dialog
: 此 dialog 出現時 除了此 dialog 以外 page 的 input 都會被 disabled
: 所以不會有其他 UI events
: 當 alert("A") dialog 執行時 內部也有個 event loop 在取 event 出來執行
: 所以會取到 event2 並執行 alert("C")
: 當你按掉 alert("C") 之後 會立刻執行 alert("D")
: 再按掉 alert("D") 又會回到 alert("A") 的內部 event loop
: 再按掉 alert("A") 之後 會執行 alert("B")
: 所以會看到 alert("A") 出現後 立刻出現 alert("C")
: 然後結束 alert("C") 立刻出現 alert("D")
: 然後結束 alert("D") 回到 alert("A")
: 然後結束 alert("A") 立刻出現 alert("B")
: 2. IE
: 當 IE parse 完 js 之後會立刻執行 所以才會
: 出現 A 按掉A之後出現 B 按掉 B 之後出現 C 按掉 C 之後出現 D
: ps: 至於 console.log("A") 會依序出現
: 是因為執行 console.log("A") 時
: 並不會偷偷跑 event loop
: 所以 C D 不會偷跑囉
: ※ 引述《senser (彷彿曾經一起死過)》之銘言：
: : alert在不同thread下(iframe)到底會怎樣我倒是沒有研究過
: : 我把您的code改成
: : var $ = function(id){return document.getElementById(id);};
: : $('ifa').src = 'javascript:alert("A");alert("B")';
: : $('ifb').src = 'javascript:alert("C");alert("D")';
: : 我剛剛試的結果
: : 意外發現FF下會先出現A(很快來不急按) 然後被C蓋住 之後D 回到A 最後B
: : 這有點兩個alert一起出現的味道(只是被蓋住了)
: : IE的結果就是同一時間只有一個alert 然後ABCD
: : 這跟browser的實作有關
: : 我只能推斷 FF的alert出現時 容許其他的thread的alert也出現
: : (不確定是 出現兩個 一個被"蓋住" 或是同一個alert box然後內容被取代
: : 在我的FF中沒辦法用滑鼠移動alert box)
: : 而IE的UI不容許這種情況出現
: : 然後回到問題
: : 在兩個thread併行下 ACBD交叉出現我覺得是有可能的
: : (但我不知道哪個browser可以 也沒試著去製造出來過)
: : 但是在一個event-driven 的single thread中(前篇文章) 是不會發生的
: : 一個callback只會執行完在去執行下一個 不會互相跳來跳去
: : ==============
: : 各家瀏覽器對alert的實作略有不同
: : 一般當alert出現時 產生alert那段程式會暫停 直到按了之後在繼續
: : 然而有些瀏覽器在alert出現時 會繼續dispatch的動作
: : dispatch進去的handler中 如果是UI trigger的 他不會執行
: : 但如果是non-UI 的event handler 像是ajax的callback
: : 在某些browser中是會同時執行的 即使你的alert還掛在那裏
: : 所以用alert debug的習慣是非常不好的
: : 在你還沒按下時 可能有東西就跑起來了
: : 以致於你alert出來的變數也有可能被影響 而看到錯的值
: : 真的用在application中更是有可能造成錯誤 (confirm,prompt等等都一樣)
: : 根據你甚麼時候按下去 你的那段程式才會繼續跑
: : 但是你的non-UI event在背後一樣的dispatch然後fire (如page load,timeout)
: : 所以希望大家改掉直接用這種東西當UI的習慣 避免不必要的timing issue
: : 全部的UI都要自己兜出來比較好
: : ===
: : 這裡就有現成的例子
: : 剛剛用FF看 好像是CDAB (按掉CD時A或若隱若現)
: : 如果你沒有注意那個若隱若現的A 你就會以為他的順序真的是CDAB這樣
: : 然而如果你改成console.log("A")
: : 就會知道他的真正的順序是ABCD
: : 給大家參考:D
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 71.107.60.113
→
11/07 19:36, , 1F
11/07 19:36, 1F
→
11/07 19:37, , 2F
11/07 19:37, 2F
→
11/07 19:38, , 3F
11/07 19:38, 3F
→
11/07 19:43, , 4F
11/07 19:43, 4F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 11 之 11 篇)：