>>> But it still has the same braindamage: one system call per loop >>> invocation, and we can do better. I would much rather see fdwalk() in SUS. >> >> Why would we bother to do better? >> >> System calls are cheap, and usually you actually do want to do >> something about the fd, so you actually want to iterate over them. >> >> I'd much rather have simple cheap interfaces than anything else. If >> SuS has a F_NEXT fcntl, let's just do that thing. Much simpler than >> doing something more complex and then just having to emulate the >> simple thing in user space anyway. >> >> If a standard interface exists, we should just use it. >> > > I went back and looked at the post, and also the discussion on the SUS > mailing list. > > The proposal for FD_NEXT was rejected with some serious vitriol. > > fdwalk() was considered just more palatable since there is an existing > implementation (in Solaris) and since it might be possible to provide a > way to hide specific fds from fdwalk(), but a much bigger issue raised > is that *ALL* of these interfaces are inherently broken. Closing random > file descriptors is: > > a) inherently racy in a multithreaded environment; I would say two things. 1) I know and I agree we _can_ misuse the interface. but many already existed interface also can be misused. 2) As I already explained this can be used correctly. So, I have a question. Why do you bother a possibility of misuse? Of if you didn't point out misuse, can you please point out a real world use case of multi threads + fd interation? > b) unsafe because there might be file descriptors used by libc itself. I agree this. Even though almost developer don't use libc message catalogue and we can avoid such issue by using nextfd() + fcntl(O_CLOEXEC). > Instead, from the resolution text: > >> Therefore, the rest of this proposal seeks to document the problem >> with closing arbitrary file descriptors, and a new bugid will be >> opened to propose standardizing some recent interfaces and interface >> extensions first appearing in Linux (new interfaces such as pipe2( ), >> accept4( ), mkostemps( ), ..., and extensions like fopen(,"we")) to >> guarantee the atomic creation of file descriptors with the cloexec >> bit already set, as was already done in the standard with O_CLOEXEC >> in open( ) and F_DUPFD_CLOEXEC in fcntl( ). See also 0000368 for >> a related proposal to require CLOEXEC on hidden descriptors. > > I say we ask the new glibc people to provide fdwalk() since it already > has an implementation history (and because it can be implemented without > new system calls, thereby working on old kernels), but the *big* > takeaway from this is that if there is way to create a file descriptor > so that it doesn't have O_CLOEXEC set from the very beginning, *that* is > what we need to fix. Yeah, I don't think fdwalk() is problematic. It's an option if I understand Alexey's mail correctly. but I disagree almost all developers should fix a design and rewrite their applications. In theory, they can avoid glibc or they can rewrite all of their code or avoid linux. but there is one problem. unrealistic. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
