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. 根本没有类型安全——如果系统调用需要 achar *并且程序员提供了 a 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 回答