libevent のソース コードを読んでいますが、呼び出す必要がある場合はepoll_create
、代わりに syscall を使用します。
int epoll_create(int size)
{
return (syscall(__NR_epoll_create, size));
}
後者の場合、パフォーマンスが向上しますか?
syscall()
システムコールを実行するための汎用関数です。現在の C ライブラリが実行中のカーネルより古い場合でも、システム コールを実行できるため、使用可能なすべてのシステム コールがサポートされていません。
Linux ではepoll_create()
、ライブラリ関数ではなくシステム コールです。ユーザー空間からカーネル空間への切り替えとその逆のコスト、および呼び出し自体のコストを考慮するとsyscall()
、より具体的なラッパーで可変引数呼び出し元を使用することに関連するオーバーヘッドは、存在するとしてもおそらく無視できます。
の主な問題はsyscall()
、パフォーマンスよりもプログラミング インターフェイスに関係しています。
タイプ セーフはまったくありません。システム コールが を期待しchar *
、プログラマが を提供したchar
場合、呼び出しが期待どおりに機能しない可能性があります。コンパイラは、このような間違いを防ぐことができません。
基になるカーネル インターフェイスを変更せずに提供するため、ユーザー アプリケーションで直接使用するのにはあまり適していないことがよくあります。
一方で、libc
問題のシステム コールのラッパーを意識して持っていることに依存しないため、互換性の観点からは有利です。
あなたが見ているものはかなり期待されています。カーネルを調べてみると、ほとんどの参照epoll_create()
がarch
ディレクトリ内にあることがわかります。つまり、それらはアーキテクチャに大きく依存していることを意味します。そのため、ユーザー空間から直接呼び出すことができないのはかなり標準的です。
効率については、man syscallを見てください。
そこに記載されているように:
Often the glibc wrapper function is quite thin, doing little work other than
copying arguments to the right registers before invoking the system call, and
then setting errno appropriately after the system call has returned.
いいえ、通常、この実装によってパフォーマンスに大きな影響はありません。