同じアプリケーション実行で同じ lib/file に対して dlopen を 2 回使用すると、両方のケースで同じハンドルが生成されますか? これに対する保証はありますか (短い実験で、少なくとも私のボックスではそうであることが示されました)?
私は現在、小さなプラグイン システムをいじっています (好奇心から)。この観察された動作に何らかの保証があれば、このアドレスをプラグインのキーとして使用して、重複した読み込みを防ぐことができます。
同じアプリケーション実行で同じ lib/file に対して dlopen を 2 回使用すると、両方のケースで同じハンドルが生成されますか? これに対する保証はありますか (短い実験で、少なくとも私のボックスではそうであることが示されました)?
私は現在、小さなプラグイン システムをいじっています (好奇心から)。この観察された動作に何らかの保証があれば、このアドレスをプラグインのキーとして使用して、重複した読み込みを防ぐことができます。
はい。dlopen(3) linux man ページには次のように書かれています。
If the same library is loaded again with dlopen(), the same file handle is returned. The dl library maintains reference counts for library handles, so a dynamic library is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it.
ところで、Linux システムでは、私の例のmanydl.cが示すように、多数 (数十万) の共有ライブラリを dlopen できます。主な制限はアドレス空間です。したがって、実際には、気にしないことdlclose
は可能です。
(dlopen された共有ライブラリに、奇妙でリソースを消費するコンストラクタまたはデストラクタ関数がない限り)
2017 年 12 月に追加:
関連するのは、 に渡される正確なパス文字列であることに注意してくださいdlopen
。したがって、"./foo.so"
and "././foo.so"
(または"../foosymlink.so"
wherefoosymlink.so
は へのシンボリック リンクfoo.so
) を使用すると、dlopen されたハンドルが異なり、場合によっては、その共有ライブラリの 2 つのインスタンスの奇妙な動作が発生する可能性があります。
2019 年 6 月に追加:
Drepper のHow to write shared librariesペーパーも読んでください (共有ライブラリの使い方もよく説明されています!)。