On Fri, 1 Aug 2003, Dave Butenhof wrote:
DB>Harti Brandt wrote:
DB>
DB>>On Fri, 1 Aug 2003, Alexander Terekhov wrote:
DB>>
DB>>AT>Harti Brandt wrote:
DB>>AT>[...]
DB>>AT>> I wonder how one would implement a per-thread current directory
DB>>AT>> in an environment where there is no 1:1 mapping between user
DB>>AT>> threads and kernel threads.
DB>>AT>
DB>>AT>Something similar to (but probably a bit less convoluted ;-) )
DB>>AT>a per-thread signal mask, I guess.
DB>>AT>
DB>>AT>> While I could think of ways, they seem too convoluted to me.
DB>>
DB>>Given that I have only one per-process current working directory this
DB>>would force me to intercept all systemcalls that contain pathnames and
DB>>fiddle with these, doesn't it?
DB>>
DB>>
DB>Yes, very likely, if you insisted on doing this on a kernel that's not
DB>designed to support it. Of course you'd also need to synchronize your
DB>kernel threads to be sure that only one could hit such a point at any
DB>time since you can have only one process kernel state at a time.
DB>
DB>This doesn't really even have anything to do with whether you've got 1:1
DB>or M:N mapping of threads. If your kernel has a CWD per process and
DB>you're trying to make it per-thread, you're in trouble.
That's just what I was trying to get. When Posix requires me to re-design
my Unix kernel to fit into Posix's thread model, something is wrong. With
Posix, not the kernel. If I have 1:1 mapping things may actually be easy,
because I can move the cwd from the per-process structure to the
per-process structure. If I have a M:N mapping, I must handle this in user
space and repeating half of namei() in the pthreads library is a clear
sign of wrong design (of the specification).
DB>
DB>But there's nothing unique about this. If you want to have multiple
DB>threads within a process then each needs its own registers, including
DB>stack and instruction pointers. In POSIX, each has its own signal mask.
DB>If you want each to have its own "security persona", you need to store
DB>that. If each has its own CWD, you need to store that, too. To do M:N
DB>you either need to explicitly context switch each piece of data
DB>(expensive when they're kernel state), or you need abstracted
DB>user-managed contexts. In our case, the kernel gets "all this stuff"
DB>through the thread register. Adding a per-thread CWD would be a trivial
DB>matter of adding the field to the "shared area".
So that comes down to the question that I saw earlier in this thread:
if a thread has everyting a process has, what's the difference between
them? I cannot pin it down, but I have the feeling that if you find
yourself re-implementing the kernel in libpthreads there is something
with the model. If you find that you can globally rename process -> thread
in the kernel, something is wrong with the model. Anywhere there is a fine
border between things a thread should have and what it should not have...
Methinks that the CWD is and should stay a per-process attribute, as is
the root directory.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
yyyyyy@xxxxxxxxxxxxxxxxxxx, yyyyy@xxxxxxxxxxx
|