linux pipe 文件,為什么Linux重用管道()分配的文件描述符

I'm seeing an issue using both sockets and pipes in Linux. Specifically, we call pipe(), which allocates the next two available file descriptors... let's say 10 and 11. Then we call accept() on a socket, expecting it to allocate 12. Instead, it allocates 11.

我在Linux中看到了使用socket和管道的問題。具體地說，我們調用pipe()，它分配下兩個可用的文件描述符……假設是10和11。然后我們調用套接字上的accept()，期望它分配12。相反,它分配11。

We've tested a bit, and it seems the second FD returned from pipe() is always available for reuse by other syscalls that create file descriptors.

我們已經進行了一些測試，似乎從pipe()返回的第二個FD總是可以被創建文件描述符的其他syscalls重用。

Can anyone explain this?

誰能解釋這個?

2 个解决方案

#1

4

That would imply that someone is closing the file descriptor in question some time after the call to pipe and before the second syscall. For example, if you fork off some other process to do stuff on one end of the pipe, you might be screwing up your code that closes the end of the pipe used by the other process and closing the wrong end of the pipe. Or just about anything else that might call close on some file descriptor might be closing the wrong thing.

這意味着在調用pipe之后的一段時間以及第二個syscall之前，有人正在關閉有問題的文件描述符。例如，如果您在管道的一端做一些其他的事情，您可能正在搞砸您的代碼，關閉另一個進程使用的管道的一端，並關閉管道的錯誤一端。或者其他任何可能在文件描述符上調用close的東西都可能是關閉錯誤的。

#2

0

Maybe the flag SO_REUSEADDR is used for pipes hence you're not seeing an increment in the file descriptor number?

也許SO_REUSEADDR標志用於管道，因此您沒有看到文件描述符號中的增量?

Edit: Thanks to duck and darron for the heads up on my stupid answer. I was reading this link and if close() is called on a file descriptor, it gets reused...

編輯:感謝duck和darron提醒我的愚蠢答案。我正在讀取這個鏈接，如果在文件描述符上調用close()，它將被重用……

Hope this helps, Best regards, Tom.

祝你好運，湯姆。