2012-10-09 88 views
0

我正在閱讀libevent的源代碼,當它需要調用epoll_create時,它使用了系統調用insteaded。syscall的效率

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

後一種情況會提高性能嗎?

+4

改進**什麼**?問題標題非常具有誤導性。 –

+2

顯然,'epoll_create()'是在內核中實現的,調用它的唯一方法是通過系統調用。 –

回答

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.

所以,不,通常沒有大的表現本實施打擊。

1

syscall()是執行系統調用的通用函數。即使當前C庫比正在運行的內核老,它也允許執行系統調用,因此不支持所有可用的系統調用。

在Linux上,epoll_create()是系統調用,而不是庫函數。考慮到從用戶空間切換到內核空間和返回的成本以及調用本身的成本,與使用調用程序通過更具體的包裝器使用變量syscall()相關的任何開銷可能可以忽略不計(如果它完全存在)。

syscall()的主要問題有它的編程接口,比它的性能做多:

  1. 毫無類型安全可言 - 如果系統調用需要一個char *和程序員提供了一個char ,這個電話很可能無法按預期工作。編譯器無法防止此類錯誤。

  2. 它提供了沒有修改的底層內核接口,這通常不太適合在用戶應用程序中直接使用。

在另一方面,它不依賴於libc意識到並具有用於所討論的系統調用,這是從一個點的相容性的優點的包裝。

+0

非常感謝,你的描述很清楚。 – cheneydeng