>And no, I'm not fond of such irregular ways to pass file descriptors, but >we can't kill ioctl(2) with all weirdness hiding behind it, more's the pity...
Yeah, there are a number of calls which supposed work on one but have a second argument which is also a file descriptor; mostly part of ioctl(). >> In those specific cases where a system call needs to convert a file >> descriptor to a file pointer, there is only one routines which can be used. > >Obviously, but the problem is deadlock avoidance using it. The Solaris algorithm is quite different and as such there is no chance of having a deadlock using that function (there is a bunch of functions) >The memory footprint is really scary. Bitmaps are pretty much noise, but >blowing it by factor of 8 on normal 64bit (or 16 on something like Itanic - >or Venus for that matter, which is more relevant for you guys) Fair enough. I think we have some systems with a larger cache line. >Said that, what's the point of "close won't return until..."? After all, >you can't guarantee that thread with cancelled syscall won't lose CPU >immediately upon return to userland, so it *can't* make any assumptions >about the descriptor not having been already reused. I don't get it - what >does that buy for userland code? Generally I wouldn't see that as a problem, but in the case of a socket blocking on accept indefinitely, I do see it as a problem especially as the thread actually wants to stop listening. But in general, this is basically a problem with the application: the file descriptor space is shared between threads and having one thread sniping at open files, you do have a problem and whatever the kernel does in that case perhaps doesn't matter all that much: the application needs to be fixed anyway. Casper -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
