問題タブ [kqueue]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
linux - kqueue/kevent で epoll_wait をエミュレートする方法はありますか?
kevents を作成した一連のファイル記述子のリストがあり、読み取りまたは書き込みアクセスの準備ができているそれらの数を取得する方法があるかどうかを調べようとしています。
epoll_wait が提供するような、「準備が整った」ファイル記述子のリストを取得する方法はありますか?
haskell - kqueueでのHaskellの並行性
並行アプリケーションを作成し、エラーを見つけました:
buildFdSets:ファイル記述子が範囲外です
私のFreeBSDでは、1つのプロセスでのファイル記述子の数に対するOSの制限であることがわかりました1024
。の限界ですselect()
。また、別のアプローチがあることも学びましたkqueue()
。
私の質問は次のとおりです。
- ファイル記述子の制限を勝ち取る方法は?
- haskellプログラム
kqueue()
の代わりに使用する方法は?select()
c - イベント駆動型アプリケーションの IPC ソリューションの選択
私は現在、Linux での epoll および他のプラットフォームでの同等のテクノロジを中心に設計された、かなり大規模なシングルスレッドのイベントベースのアプリケーションに取り組んでいます。現在、2 つのインスタンスを通信させたい場合は、通常、同じマシン上で実行されているかどうかに関係なく、ソケットを介して行われます。パフォーマンス上の理由から、同じマシンの通信を高速化するために何らかの形の IPC を使用することを想定しています。ここで、どの IPC メカニズムを使用するかを決定する必要があります。
私にとって重要な要素は次のとおりです。
- 完全な再設計なしのイベント駆動型 -- IPC メカニズムが epoll にうまく適合しない場合、それは私にとって何ヶ月もの作業が失われることになります
- 高速 -- このメカニズムがソケットよりも高速でない場合、時間をかけて実装する価値はありません
- 柔軟で、実行中に (再) 構成可能 -- これにより、MPI などを排除できると思います。
- マルチスレッドは必要ありません。
すべてが同じパラダイムを使用している限り、プラットフォームごとに異なるメカニズムを使用したいと考えています。また、プラットフォーム固有のバインディングのために、C / C++ / Obj-C についても必要なだけ深く掘り下げたいと思っています。
なにか提案を?
ありがとう。
iphone - iOSの場合、アプリはファイルが別のプロセスによって書き込まれなくなったかどうかをどのように判断できますか?
私の質問はこれと非常によく似ています。kqueue()を使用してディレクトリの変更を監視する最適な方法は何ですか?しかし、私はそこでの答えに満足していません。
ファイルがアプリのDocumentsディレクトリにコピーされたときに通知されるkqueue設定があります。もちろん、コピーが始まるとすぐに通知が出ますが、いつ完了するのか知りたいです。確かに、変更時間をポーリングするよりも良い方法はありますか?
python - OSX で python select kqueue を使用して、外部アプリケーションによるファイル作成を監視します
通常、1 時間のオーディオ録音セッションを mp3 ファイルにトランスコードするには、20 分ほどかかります。
OSXアプリケーションgaragebandがそのmp3ファイルの書き込みを終了したときに、pythonスクリプトを使用して一連のpythonコードを実行したいと考えています。
外部アプリケーションがファイルへのデータの書き込みを完了し、そのファイルを閉じたことをPythonで検出する最良の方法は何ですか. kqueue と epoll について読みましたが、OS イベント検出のバックグラウンドがなく、良い例を見つけることができなかったので、ここで求めています。
私が現在使用しているコードは次のことを行い、よりエレガントなものを探しています。
ios - iPhoneのkqueue?
Linuxサーバーをiosに移植しています。これは、OSX で kqueue を使用してソケットやその他のイベントを処理する、シングル スレッドのイベント ドリブン設計です。iOSに似たようなものはありますか?
ありがとう!
python - Python で更新されたファイルをオンザフライで読み取る
ファイルを解析する 2 つの Python スクリプトを作成しています。1 つは標準の UNIX ログ ファイルで、もう 1 つはバイナリ ファイルです。これらを監視する最善の方法を見つけようとしているので、更新されたらすぐにデータを読み取ることができます。これまでに見つけた解決策のほとんどは Linux 固有のものですが、FreeBSD で動作させるにはこれが必要です。
明らかに、X 回ごとにスクリプトを実行するのが 1 つの方法ですが、これは総体的で非効率的です。Python アプリをバックグラウンドで継続的に実行してファイルを監視し、ファイルが変更/更新されたときにそれを処理する場合、最善の策は何ですか?
c - パフォーマンスを向上させるために select() を kevent() に置き換えるにはどうすればよいですか?
Kqueue は、カーネルとユーザーランドの間で効率的な入出力イベント パイプラインを提供します。したがって、メイン イベント ループの繰り返しごとに kevent(2) へのシステム コールを 1 つだけ使用しながら、保留中のイベントを受信するだけでなく、イベント フィルタを変更することもできます。これは、poll(2) や select(2) などの従来のポーリング システム コールとは対照的です。これらのシステム コールは、特に多数のファイル ディスクリプタでイベントをポーリングする場合に効率が低下します。
それはいいです。私は自分のサーバーに FreeBSD をターゲットにしており、かなりの量のネットワーク ソケット fd を処理しています - それらすべてで select() を使用し、誰からデータを読み取るかを考え出しています。kevent() 呼び出しを使用してパフォーマンスを向上させたいと思います。それが目的だからです!
ここで FreeBSD の kevent の man ページを読みましたが、それは不可解であり、それを説明する適切なリソースが見つかりません。kevent を使用して select を置き換える例は、私の問題を解決し、kevent() の使用方法をよりよく理解するのにも役立ちます。
objective-c - 私のために再帰的な監視を処理するファイル システム イベント/kqueue 用の適切な objc ライブラリ ラッパーはありますか?
特定のディレクトリ内のファイルが変更されたときに通知を受け取る OSX (Snow Leopard) アプリを作成し、変更された特定のファイルのパスにアクセスしたいと考えています。
File System Events
または のいずれかを使用してこれを実行できることはわかっていますkqueue
。前者は、変更された特定のファイルの詳細を提供しません (監視しているディレクトリのスナップショットを作成し、それをスキャンして変更されたファイルを見つける必要があります)。後者は再帰的な監視をサポートしていません (親ディレクトリ内のすべてのファイルとディレクトリに監視を再帰的に追加する必要があります)。
スナップショット/再帰の楽しみを処理するライブラリを探しましたが、見つかりません。UKKQueue
低レベルのkqueue
ものの良いラッパーのように見えますが、再帰を行うようには見えません。についても同じですGTMFileSystemKQueue
。SCEvents
の良いラッパーのFile System Events
ように見えますが、変更された特定のファイルを見つけることを処理していないようです。
私が望むことを行い、これらのテクノロジのいずれかの objc プロジェクトに適したライブラリはありますか?
networking - kqueue の制限は何ですか?
libev ( source ) のドキュメントには、次のように書かれています。
Kqueue は特筆に値します。この記事の執筆時点では、NetBSD を除くすべての BSD で壊れていました (通常、Darwin を除いて、ソケットとパイプ以外では確実に動作しませんが、Darwin ではもちろん完全に役に立ちません)。
また、次のことにも言及しています。
kqueue syscall は既知のすべてのバージョンで壊れています。ほとんどのバージョンはソケットのみをサポートし、多くのバージョンはパイプをサポートしています。
では、kqueue の制限は何ですか? これらの制限はどこに文書化されていますか? 初期の調査では、古いオペレーティング システム (Mac OS X 10.3) でのカーネル パニックへの言及と、不正確または不完全なドキュメントに関する苦情が見つかりました。これらの情報源がどれほど信頼できるかはわかりません。
特に、kqueue がソケット (AF_UNIX、AF_INET、および AF_INET6) で確実に動作する場合は、気にしません。Mac OS X と FreeBSD の実装に関する情報に特に興味があります。