On Wed, Apr 3, 2013 at 5:59 PM, Glenn Fowler <[email protected]> wrote: [snip] > my knee jerk reactions > > (1) I don't see how tmp files spilling to shared mem can work in general > since getting independent shared mem ops to provide contiguous memory > is a portability issue,
Erm... usually this behaviour is not portable... > e.g., how do write(2) calls to a shared mem region > automatically extend the region -- and how can that happen when that > region fd is passed to another non-ast/ksh application Another issue is... if /tmp is out of space when you're usually running out of other important system resources, too (for example on Solaris /tmp is a swap-disk... if /tmp is full then you're out of ram and out of swap space...). It's only the tip of the iceberg and the only question is: "... where are you going to be hit..." and not "... are we going to hit the iceberg..." (if /tmp is full then a lot of applications are going to blow-up). > (2) even if (1) is solvable, some sftmp() callers may expect a real path > name that may be passed on to other applications -- /dev/fd or some > variant may be used but is it portable to do that with shared mem fds? > we have already run into /dev/fd inconsistencies with socket fds > > (3) using statvfs() is a wormhole -- how would sftmp() know what size > threshhold to request -- no matter what it uses there will be apps that > exceed that threshold, or there will be multiple concurrent apps getting > the green light at the same time and choking each other out Erm... using |statvfs()| is likely generating problems, too. There are ram-/swap-based filesystems which expand and shrink when files are stored/grown/truncated/removed in them but always report 100% full or some "guessed" value (Solaris tmpfs used for /tmp can behave like that in "zones" (=Solaris containers)). In such cases |statvfs()| is pretty much useless. Another issue with |statvfs()| is that it can be a very very expensive system call which causes the filesystems to do some accounting. IMO putting that into a code path to obtain a temporary file is not... wise (from the performance viewpoint). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
