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
