在我的linux中，从posix库或内核中调用close（）的哪个版本？

当我man -a close，第一页是POSIX手册页，然后我有一个close(2)，（2表示系统api或内核func）。这意味着至少有两个版本的close()。在我的linux中，从posix库或内核中调用close（）的哪个版本？

例如，这段代码是这样的：

int fd = open("xxx"); 
........ 
close(fd); -----here, which version is called, 
        is that one from the POSIX lib, or the raw system API?

PS：因此，我的linux系统，包括大多数系统API调用POSIX包装，如何辨别我的代码是否被调用POSIX lib或原来的系统API ？

来源

2012-06-29 basketballnewbie

“这意味着至少有两个版本的close（）。”

不，这意味着有两个版本的文件需要关闭。

来源

2012-06-29 06:32:08 nos

据我所知，有几种情况我们需要通过某种方式显式声明我们是使用POSIX还是SYSTEMV风格（使用信号量或线程等等），在这种情况下，它是否意味着linux保留一些函数的两个实现？一个COM从POSIX，但其他人适合一些旧式？ – basketballnewbie

POSIX不是一个库，它是一个标准。手册页的POSIX版本告诉你POSIX标准说明函数应该做什么（以及基于哪个版本的POSIX）。如果您只依赖本页中描述的行为，那么您的代码应该在所有实现POSIX标准的系统上工作（只要它们实现了足够的版本）。

Linux版本的联机帮助页告诉你函数实际上在你的系统上做了什么。在绝大多数情况下，这里描述的行为将是POSIX页面中描述的行为的超集，即Linux行为将遵循POSIX标准，但它也可能定义POSIX未定义的情况或者函数可能接受其他选项不是由POSIX授权的。

如果您依赖于POSIX未指定的任何行为，那么您的代码可能仅适用于Linux系统。

来源

2012-06-29 06:45:22 sepp2k

tks，sepp2k.you很清楚.POSIX不是一个库，它是一个标准的-----------如果有一些行为本来不符合Linux的POSIX，linux是否做了一些总结lib来满足它？如果有的话，任何例子？ – basketballnewbie

POSIX要求'close'是一个取消点，而Linux内核对线程取消一无所知，所以'close'的用户空间libc包装必须对其进行修补。 –

userspace libc wrapper for close _____ libc wrapper为我们的应用程序封装了任何系统api，例如，如果我们调用close/open或其他系统api，wo实际先调用libc，然后libc调用kernel for usr？如果是这种情况，为什么应该存在libc？ – basketballnewbie

在我的linux中，从posix库或内核中调用close（）的哪个版本？

回答

相关问题