libusbは、同じ実行可能ファイルにリンクされた2つの独立したライブラリから同時に使用される可能性があります。たとえば、アプリケーションにプラグインのようなシステムがあり、ユーザーがさまざまなモジュールをプログラムに動的にロードできる場合、2つの独立して開発されたモジュールが両方ともlibusbを使用する可能性があります。

libusbは、これらの複数のユーザー・シナリオを可能にするように作成されています。 libusbの2つの"インスタンス"は干渉しません: あるユーザーからの libusb_set_option() 呼び出しは、他のユーザーの同じ設定に影響しません。ユーザーは、その誰かが libusb_exit() などを呼び出した後も、引き続きlibusbを使用できます。

これは、libusbのコンテキスト(context)の概念によって可能になります。あなたが libusb_init() を呼び出すと、(オプションで)コンテキストが与えられます。あなたは、このコンテキスト・ポインタを、この先使うlibusb関数に渡すことができます。

より単純なアプリケーションのために物事を単純に保つために、(他のコードが同じプロセスからlibusbを使用しようとしないことが確実である限り)コンテキスト・ポインタを必要とするすべての関数にNULLを渡すことは合法です。NULLを渡すと、デフォルトのコンテキストが使用されます。デフォルトのコンテキストは、他のコンテキストが存在しないときにプロセスが libusb_init() を初めて呼び出すときに作成されます。コンテキストは、libusb_exit() 処理中に破棄されます。

デフォルトのコンテキストは参照カウンターであり、共有できます。つまり、 libusb_init(NULL) が同じプロセス内で2回呼び出された場合、2人のユーザーは同じコンテキストを共有することになります。デフォルトのコンテキストの後片付け(deinitialization)と解放は、最後のユーザーが libusb_exit() を呼び出したときにのみ発生します。つまり、デフォルトのコンテキストは、参照カウンターが0から1になると作成および初期化され、参照カウンターが1から0になると後片付け(deinitialization)および破棄されます。

libusb関数のサブセットのみが関数定義でコンテキスト・ポインターを必要とするのはなぜか疑問に思われるかもしれません。内部的には、libusbはコンテキスト・ポインタを他のオブジェクト(libusb_deviceインスタンスなど)に格納するため、それらのオブジェクトからコンテキストを推測できます。