Ted, Thanks for your patience with me.
I thought I had this down, and I thought that the only real problem is *immediate* re-use and the race conditions it causes and that for all other cases, scripts can find a way to work around things. But: But truly, your example stumps me atm. Completely understood your point that the "real" solution is to properly use trap in all scripts. What that also entails in practice is working with every debian package and program .. . If A calls B that calls C which then calls D, and they are all programs written in different languages, some of which don't even allow arguments, etc. But, indeed, that's not the kernel's "problem." In the meanwhile, if deep inside D, I am generating files that A needs to be aware of (again, A through D are in different languages, with their own broken utilities), I can always add additional information and make it unique. I can use random strings to make it unique enough, or if I need deterministic, I can add pid + start time (jiffies of the proc) + linux start time (btime from /proc/stat) to make it unique enough. If I truly have a unique PID, I never have to worry about any of this, I guess. OTOH, I guess if one has to write cleaner/other meta scripts without proper traps, the cleaner can simply check if linux's PID counter is too close to the current PID, and if so, refrain from drastic actions. For the latter, I wonder if there's a way to get "current PID counter." Thanks again, Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
