問題タブ [watchman]

反応ネイティブ プロジェクトを開始したいのですが、手順は次のとおりです。

まずreact-native init testproject それから react-native run-ios

オペレーティング システムのエディション: OS X 10.12

JVM プログラムの socket/bser インターフェイスを介してウォッチマンを統合しています。

私は奇妙なタイミングを見ています:

1. ファイルはビルド システムによって書き込まれます (小さなテキスト ファイル)
2. bser インターフェイスでウォッチマン通知を受け取ります
3. bser サブスクリプション通知をリッスンするスレッド A は、更新を別のスレッドのキューに入れます。
4. スレッド B はキューを読み取り、変更されたファイルを読み取り、ファイルのデータをネットワークに送信します。

ただし、どういうわけか、スレッド B は空のファイルを読み込んでいます。

これは、ある時点で有効に空であると想定しています。たとえば、IO/syscalls は次のようになります。

1. ファイルの内容をクリアする
2. チャンク 1 の書き込み
3. チャンク 2 の書き込み
4. ファイルを閉じる

そして、スレッド B がステップ 1 と 2 の間でファイルを読み取っていると思います。または、4 が結果がフラッシュされたときの場合は、1 と 4 かもしれません。

私の混乱は2つあります。

1）ウォッチマンのデフォルトの20ミリ秒の待機はこのようなことを説明すると思いました.スレッドBが読み取りを行ったときはもちろん、スレッドAの更新のみが表示され、ステップ4の後にデータの書き込みが完了しました.ファイル。

2) ウォッチマンが最初の syscall (ステップ 1 など) について「早すぎる」と言って、それが空のファイルである間に結果を読んだとしても、別の syscall/watchman 通知があるはずです。現在のコンテンツ」。

FWIW/奇妙なことに、Java WatchService API を使用しているときに、これとまったく同じ動作が見られました。ここでは、inotify イベントを取得しましたが、ファイルを「すぐに」読み取ったため、結果が空または部分的になり、フォローアップが行われませんでした。残りのデータが利用可能になったときの inotify イベント。

これは WatchService のまぐれ/ニュアンスであると想定していたので、ファイルを読み取る前に変更時間を確認し、変更時間が 2 秒を超えていることを確認してからファイルが「完了」したと想定することで、その時点で解決しました。 .

(これは、ビルド プロセスが 100 ミリ秒以上ごとにデータのチャンクを書き込む可能性がある場合に、書き込まれる ~100 MB 以上のファイルも処理することに注意してください。ただし、WatchService を使用すると、本質的に単一の連続書き込みであったものに対して数百の inotify 通知が表示されました。)

WatchService コードを watchman に移植したとき、この「ensureSettled」ハックを削除しました。なぜなら、watchman の 20 ミリ秒のセトリング期間 (私が使用していた 2 秒よりもはるかに短いですが、これがデフォルトです) を想定していたからです。 beta の WatchService は、問題にならないことを意味します。

しかし、ウォッチマンに移植されたコードを使用して 1 日以内に、WatchService の場合と同様に、空のファイルの読み取りが見られます。

私が欠けているものについてのアイデアはありますか?

ensureSettled ハックを元に戻すことはできますが、この時点で何が起こっているのか知りたいです。

ソケット インターフェイスを介して監視を確立し、変更をサブスクライブしています。

着信 PDU ごとに、マップに「警告」キーがある場合、ドキュメントが示唆するように、コンソール/ユーザーに警告を出力します。

ただし、オーバーフローが発生した場合、「警告」キーを一度だけ取得するのではなく、すべての着信 PDU に同じ警告 (「再クロールが 1 回発生しました」) が何度も (AFAICT?) あるように見えるので、同じエラーメッセージでコンソールをスパムすることになります。

私にとっては、Watchman が "警告" キーをオーバーフロー イベントごとに 1 回だけ送信した方が望ましいでしょう。それ以外の場合は、コンソールのスパムを回避するために、「ユーザーに既に表示されている警告」をキャッシュする必要があると考えています。

また、一般的なオーバーフロー動作に関して、警告には次のように記載されています。

しかし、サブスクリプションをキャンセルして再登録することなく、警告をリセットする方法があればいいのにと思います。たとえば、現在、control-c でプログラムを強制終了し、watchman watch-delコマンドを実行してから、プログラムを再起動する必要があります。

これは内部で自動化できます。たとえば、プログラムに「オーバーフローが発生しました」という警告メッセージを検出させ、サブスクリプションを強制終了し、 を発行してwatch-delから を再発行しwatchます。

しかし、ソケットインターフェースを介して警告をリセットしたり、これを内部的に実行したりできたとしても、watch-delなぜ警告をリセットする必要があるのか​​ 疑問に思っています. （コンソールにログを記録することにより）、今は問題ありませんか？そもそもなぜwatch-del+ re-が必要なのですか?watch

たとえば、オーバーフローが常に発生していない限り、ウォッチマンが再クロールを行っているように見えます (したがって、ファイル システムとの同期が回復します) + 警告 PDU を 1 つ発行することは、すべてが正常に戻ったことを意味し、ユーザー プログラムは、理想的にはそのままでいることができます。ダム/シンプルで、同じ/既存のサブスクリプションでオーバーフロー後/再クロール後の PDU を取得し続けるだけです。

私は最初にこの問題を抱えていました: https://github.com/facebook/react-native/issues/10088

次に、この問題を解決するためにこのソリューションに従いました: https://github.com/facebook/react-native/issues/910#issuecomment-94181845

今、私が入るnpm startと[sane] Warning: Lost connection to watchman, reconnecting... 助言がありますか？

更新: これは、MacOS を MacOS Sierra に更新したときに発生し始めました。

更新: そこでreact-native run-ios、新しいコンソール ウィンドウを開いて を呼び出す実行を試みましたnpm start。それでも[sane] Warning: Lost connection to watchman, reconnecting..警告が表示されますが、バンドルがビルドされます。そのため、ウォッチマン接続が途中で壊れています。コンソールのスクリーンショットは次のとおりです。

Mac で基本的な反応ネイティブ プロジェクト (チュートリアル) を実行しようとしていますが、エミュレーターを実行したり、デバイスにデプロイしたりすると、次のようになります。

git からウォッチマンを再インストールしようとしましbrew install --HEAD watchmanたが、役に立ちませんでした。

助言がありますか？

ありがとう