> Sure, but there is *no* difference between doing so immediately and > doing so upon demand...
Sure there is. The basic requirement here is that the the OPEN_MAX limit be enforced as specified, on the total of fopen+tmpfile + open and other POSIX.1 calls (and probably some other ISO C call I am forgetting). In our case, that means the value from sysconf(_SC_OPEN_MAX), which is the soft resource limit for RLIMIT_NOFILE. Unless we change some of all of those semantics, then setting your resource limit to a value low enough that you have no free file descriptors when you call tmpfile must fail. Furthermore, a value such that you have two free when you call tmpfile must cause the second subsequent fopen/tmpfile/open/dup/etc call to fail with EMFILE. So the difference between doing so immediately and doing so upon demand is that the call that creates the potential for the later demand must immediately update some separate count of descriptors consumed for limit purposes but not actually allocated. I am in favor of further optimizing these things. But for tmpfile I was providing a quick fix for a problem holding up the smooth adoption of the new ABI, so the simple and unoptimized solution today (actually day before yesterday :) was what we needed, and that's all that should probably go into libc-2.2. The current libio code also does not circumvent the int->pointer lookup for file descriptors (we're just using the generic POSIX-compatible code). That too could and should be better optimized for the Hurd, but I am not worrying about that in 2.2, where we are already pretty stable and going just for more stability. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
