0

libevent のソース コードを読んでいますが、呼び出す必要がある場合はepoll_create、代わりに syscall を使用します。

int epoll_create(int size)
{
     return (syscall(__NR_epoll_create, size));
}

後者の場合、パフォーマンスが向上しますか?

4

2 に答える 2

2

syscall()システムコールを実行するための汎用関数です。現在の C ライブラリが実行中のカーネルより古い場合でも、システム コールを実行できるため、使用可能なすべてのシステム コールがサポートされていません。

Linux ではepoll_create()、ライブラリ関数ではなくシステム コールです。ユーザー空間からカーネル空間への切り替えとその逆のコスト、および呼び出し自体のコストを考慮するとsyscall()、より具体的なラッパーで可変引数呼び出し元を使用することに関連するオーバーヘッドは、存在するとしてもおそらく無視できます。

の主な問題はsyscall()、パフォーマンスよりもプログラミング インターフェイスに関係しています。

  1. タイプ セーフはまったくありません。システム コールが を期待しchar *、プログラマが を提供したchar場合、呼び出しが期待どおりに機能しない可能性があります。コンパイラは、このような間違いを防ぐことができません。

  2. 基になるカーネル インターフェイスを変更せずに提供するため、ユーザー アプリケーションで直接使用するのにはあまり適していないことがよくあります。

一方で、libc問題のシステム コールのラッパーを意識して持っていることに依存しないため、互換性の観点からは有利です。

于 2012-10-09T12:41:26.447 に答える
1

あなたが見ているものはかなり期待されています。カーネルを調べてみると、ほとんどの参照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.

いいえ、通常、この実装によってパフォーマンスに大きな影響はありません。

于 2012-10-09T11:52:34.587 に答える