On Tue, Nov 20, 2018 at 9:39 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Tue, Nov 20, 2018 at 10:18:29AM +0100, Pavel Machek wrote: > > > would ever rely on the pid being reused while having the descriptor > > > open. How would that make sense? > > > > I agree this is corner space, but users might be surprised that > > keeping FDs of /proc/pid/X would lead to PID space exhaustion, for > > example. > > We have a limit on the number of FDs a process can have open for a reason. > Well, for many reasons. And the typical limit is too low. (I've seen people clamp it to 1024 for some reason.) A file descriptor is just a handle to a kernel resource. All kernel resources held on behalf of applications need *some* kind of management interface. File descriptors provide a consistent and uniform instance of such a management interface. Unless there's a very good reason, nobody should be using non-FD handles for kernel resource management. A low default FD table size limit is not an example of one of these good reasons, not when we can raise FD table size limit. In general, the software projects should not have to put up with ugly workarounds for limitations they impose on themselves.
