Hi! ----
[Just some follow-up to the recent discussion] Question is: Why do we want a per-thread cwd ? Is it useful ? AFAIK the arguments are: * Pro: - Moving the cwd from global to a pre-thead makes it easier to implement thread support for existing applications <any more arguments ?> * Contra: - The per-thread cwd is locked on the current thread. Moving objects relying on this per-thread cwd to another thread (e.g. job "borrowing" or forwarding) is not possible unless we alter that's thread cwd (which means we have the same kind+class of problems we tried to solve when we tried to get rid of the global cwd) - The per-thread cwd is only known to libast... any other API will not be aware of this (Glenn: Can this we resolved by compiling existing libraries against the libast headers ?) Finally: Wouldn't it be a better solution to drop the notion of a global or per-thread cwd _COMPLETELY_ and let the applications and APIs themselves handle this... with as many dirfd's they want ? The idea would be that all APIs which currently rely on global resources like { cwd, umask, environ } get this information passed as arguments instead of relying on the global versions (we already see this movement in POSIX with the introduction of the |*at()|-APIs in XPG7 or newer additions like |posix_spawnattr_setfchdir()|/|posix_spawnattr_setenviron()|/|fexecve()| etc. ...) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers