22

ブラウザベンダーがUIスレッドのブロックを手伝いたくない理由を理解しています。しかし、なぜあるのかわかりません。

  1. Webワーカーにsleep(2)がない
  2. 同期WebSocketAPIなし

同期ファイルシステムAPIがあります。同期IndexedDBAPIもあります。私には矛盾しているように思えます。

4

5 に答える 5

15

WebWorkersで使用できる関数がない理由sleep()は単純です。つまり、関数は必要ありません。 sleepは同期関数であり(戻るまでブロックします)、WebWorkersの非同期コンテキストでは意味がありません。

WebWorkerにメッセージを送信しても、応答の待機はブロックされません。応答はメッセージとしてメッセージハンドラー関数に送信されます。応答を送信する前に一定の時間待機したい場合は、を使用せず、関数が呼び出されたときにメッセージをsleep使用して送信します。setTimeout

同様に、WebSocketデータ送信にWebWorkersを使用している場合は、メインスレッドからメッセージを受信し、WebSocketを介して非同期でパケットを送信してから、応答ハンドラーでメッセージをメインスレッドに送り返します。sleep同期機能を使用する論理的な場所はありません。

ファイルシステムのようにWebSocketに同期モードがない理由に関する限り、主な違いは、ファイルシステムがネットワーク経由でアクセスされないことです。一般的に、ネットワークベースの関数には非同期APIの方が望ましいので、それほど矛盾はないと思います。

IDBは3つのブラウザーでのみサポートされており、いずれも同期APIを実装していないため、同期APIの輝かしい例とは見なされません。実際、それは人々がAPIを定義し、それを実装することをわざわざしないという矛盾だと思います。

于 2012-10-05T17:41:38.083 に答える
9

まったく明らかではありません。TCPプロトコルもネットワークプロトコルですよね?また、アプリケーションの開発とデバッグが簡単になるため、同期モードでよく使用されます。

私の意見では、非同期モードは、I / OがUIをブロックしたくない場合に、モノスレッドアプリケーションのコンテキストで明白です。たとえば、バックグラウンドI / Oを処理するためにWebワーカーを使用する場合は、それほど明白ではありません。Webワーカーと連携して同期WebSocketを使用すると便利です。

最後に、ファイル読み取り呼び出しが迅速に行われると想定するのは賢明ではありません。常にタイムアウトにするか、IOが応答しない場合にアプリがハングするという事実を受け入れる必要があります。

于 2012-11-25T13:28:29.673 に答える
7

私にとって、それは非常に明白です。

FileSystemAPIとIndexedDBAPIはミリ秒単位で動作するため、今すぐデータを信頼できます。代わりに、WebSocket APIは少なくとも100倍遅く、データはワイルドインターネット上を飛行する必要があるため、非同期にするのは明らかです。あなたの応答は決して戻ることはできません。

ここに画像の説明を入力してください

于 2012-10-06T00:19:15.837 に答える
3

インデックス付きデータベースは、実行を長時間ブロックしません。おそらく、数ミリ秒で結果が得られ、インデックス付きデータベースに数百万のレコードが格納されることはありません。ファイルAPIと同じように、ほとんどのAPIはより高速な実行をもたらします。

また、同期APIは競合状態を引き起こし、マルチスレッド同期などを必要とするため、プログラミングが複雑になります。代わりに、メッセージベースのスレッド化はプログラミングが簡単で、同期の問題はありません。

また、ほとんどのjavascriptエンジンは安定しており、人々は非同期プログラミングの方法に精通しています。それは労働者を書くためのより簡単で唯一の方法です。これを変更するには、JavaScriptエンジンを大幅に書き直す必要があります。より多くのネイティブAPIを導入すると、ワーカープログラミングがより複雑になります。異なるOSと異なるアーキテクチャまたはデバイスwikiは、より複雑になります。

于 2012-10-05T07:33:16.040 に答える
1

V8はES2017await/ asyncを実装しているので、Promise対応のライブラリでそれを使用でき、同期APIはもうそれほど必要ありません。

于 2013-03-28T17:23:41.673 に答える