問題タブ [posix]
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 - timer_create、timer_settime、およびその他のタイマー関連関数のためにリンクする必要があるライブラリ
Linux で POSIX タイマー関数 (例: timer_create、timer_settime) を呼び出すプログラムをコンパイルすると、次のようなエラーが返されます。
どのライブラリをリンクする必要がありますか?
c - posix c 関数を使用した文字エンコーディングの変換
Windows-1251からutf-8に、またはその逆に、エンコーディングを変換するための標準のposix C関数はありますか?
c - ENOSYS で sem_open() が失敗するのを止めるにはどうすればよいですか?
2 つの Slackware Linux システムがあり、POSIX セマフォsem_open()
呼び出しが errno が 38 に設定されて失敗します。サンプル コードを以下に再現します (コードは CentOS / RedHat で正常に動作します)。
これを引き起こす可能性のあるカーネルまたはシステム構成オプションはありますか? 他の提案?
問題のあるシステムは Slackware 10.1.0 カーネル 2.6.11 /lib/librt-2.3.4.so /lib/libpthread-0.10.so ですが、同じコードはずっと古い RedHat 9 カーネル 2.4.20 /lib/librt でも動作します。 -2.3.2.so /lib/tls/libpthread-0.29.so. (CentOS 5 カーネル 2.6.18 /lib/librt-2.5.so /lib/i686/nosegneg/libpthread-2.5.so でも動作します)。
man sem_open
この errno はsem_open()
、システムでサポートされていないことを意味します。
sem_open()
ユーザー空間は動的librt
にリンクする場所librt
であり、影響を受けるシステムに存在します。
影響を受けるシステムは、POSIX セマフォをサポートすると主張しています:_POSIX_SEMAPHORES
は真であり、これをsysconf(_SC_SEMAPHORES)
確認します。
ありがとう、キエラン
編集 1: 使用中のソフトウェア バージョンの詳細を追加し、無関係なコメントを削除しました。
編集 2: /dev/shm は正常なシステムにマウントされ、不良なシステムにはマウントされません。これをマウントしても、影響を受けるシステムの動作は変わりませんでした。/dev/shm も必要だと思いますが、その前に sem_open() が失敗しており、strace がこれをサポートしています。
c++ - リリースモードでは assert(false) は無視されますか?
VC++を使用しています。リリースモードではassert(false)
無視?
linux - すべての inode はどこで使用されていますか?
すべての inode を消費する原因となっているディレクトリを特定するにはどうすればよいですか?
最終的には、ルート ディレクトリが最大数の inode を担当することになるため、どのような回答が必要なのか正確にはわかりません..
基本的に、使用可能な inode が不足しており、不要なディレクトリを見つけて選別する必要があります。
ありがとう、漠然とした質問でごめんなさい。
queue - POSIXセマフォのみを使用してウェイクアップ待機レースを回避することは可能ですか?良性ですか?
POSIXセマフォを使用して、キューを表すファイルからのアトミックなgetおよびputを管理したいと思います。完全に無関係なプロセスがキューを共有できるように、ファイルシステムに名前を付ける柔軟性が必要です。この計画ではpthreadが除外されていると思います。名前付きのposixセマフォは、すべてのプロセスが認識できるものをファイルシステムに配置するのに最適ですが、標準のCondWaitプリミティブが見つかりません。
CondWaitがプロセスによって呼び出されると、アトミックにsemに投稿され、condを待機します。他のプロセスがcondにポストするとき、待機中のプロセスは、semもアトミックにデクリメントできる場合にのみウェイクアップします。の代替
このプロセスが待機する直前に、他のプロセス信号が競合状態になるという競合状態が発生します。
並行プログラミングを行うことはほとんどないので、SOに尋ねると思いました。条件変数に標準のPOSIXカウントセマフォを使用する場合、このレースは良性である可能性がありますか?
誰かがより大きなコンテキストを必要とする場合に備えて、シェルスクリプトから呼び出すことができるアトミックキューのgetおよびput操作を構築しています。
unix - System V と Posix セマフォの違い
System V と Posix セマフォの使用のトレードオフは何ですか?
linux - 厳格すぎる権限を持つリビジョンディレクトリを作成するSubversion
今朝、私はSubversionの改訂をコミットしようとしましたが、突然、そうする許可がなくなったことがわかりました。
revsディレクトリを見ると、誰かが21000番目のリビジョンをコミットしていて、新しいディレクトリのグループ書き込み権限が何らかの理由で欠落していることに気付きました。
そのディレクトリにグループ書き込み権限を設定すると、コミットできるので、さらに1000回のリビジョンに対応できます。しかし、なぜこれが発生するのでしょうか。また、発生しないようにするにはどうすればよいでしょうか。
posix - Winsock でのファイル ハンドルとソケットの混在
私はいくつかのコードを BSD ソケットから Winsock に移植していますが、以下のケースの処理方法がわかりません。
私の元のアプリケーションは、stdin とネットワーク ソケットの両方で選択を実行します。
これを Winsock で実行しようとすると、エラー 10038 (WSAENOTSOCK) が発生します。Linux ではファイル ハンドル 0 (stdin) であったものは、Windows ではソケット (より正確には SOCKET タイプ) ではないため、これは理にかなっています。
このテストを Windows ソケットに移植する簡単な方法はありますか?
c - TCP ソケットの代わりに POSIX メッセージ キューを使用する - 「接続」を確立する方法は?
TCP 経由で通信するクライアント プログラムとサーバー プログラムがあります。代わりに POSIX メッセージ キューを使用しようとしています (もちろん、クライアントとサーバーが同じマシン上にある場合)。私の希望は、パフォーマンスが向上することです (具体的には、待ち時間の短縮による)。
私はそのほとんどを解決しましたが、「接続」を確立する方法が 1 つあります。サーバーは複数のクライアントからの接続を同時に受け入れるため、次のように TCP 接続確立プロセスをエミュレートしたくなります。
- サーバーは既知の名前でキューを開き、そこから継続的に読み取ります (
select(2)
TCP と同様に使用できます)。 - クライアントは 3 つのキューを開きます。そのうちの 2 つは任意の名前 (衝突を避けるための PID などの一意性を含む) で、もう 1 つはサーバーで使用される既知の名前です。
- クライアントは、クライアントのキュー名を含む「接続」メッセージをサーバーのキューに送信します (1 つはクライアントからサーバーへのトラフィック用に指定され、もう 1 つはその逆用に指定されます)。
- サーバーは、クライアントの接続メッセージで指定されたキューを開き、クライアントからサーバーへのキューから読み取り (選択) を開始します。
- クライアントは、既知の名前でサーバー キューを閉じます。双方向通信は、クライアントによって指定された 2 つのキュー (各方向に 1 つ) を使用して続行されます。
おそらく、この方式が一般的な TCP 方式に似ていることがお分かりいただけると思いますが、これは偶然ではありません。ただし、知りたいのは:
- それを行うためのより良い方法を考えることはできますか?
- 私の方法に潜在的な問題はありますか?
- 同じマシンで TCP の代わりにメッセージ キューを使用すると実際にパフォーマンス (レイテンシ) が向上する可能性など、他に何か考えはありますか?
以前に POSIX メッセージ キューを使用したことがないことに注意してください (以前は IBM WebSphere MQ を使用していましたが、それはかなり異なります)。プラットフォームは Linux です。