Email List: Xaustin-group-futures-lX
[All Lists]

Re: thread-private working directory

To: Harti Brandt <yyyyyy@xxxxxxxxxxxxxxxxxxx>
Subject: Re: thread-private working directory
From: Dave Butenhof <yyyyyyyyyyyyyy@xxxxxx>
Date: Fri, 01 Aug 2003 09:49:16 -0400
Cc: Alexander Terekhov <yyyyyyyy@xxxxxxxxxx>, yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
Organization: Hewlett-Packard Company
References: <OFB7D492BD.64512203-ONC1256D75.0048EE46-C1256D75.00492B68@de.ibm.com> <20030801152245.P4685@beagle.fokus.fraunhofer.de>
Harti Brandt wrote:

On Fri, 1 Aug 2003, Alexander Terekhov wrote:

AT>Harti Brandt wrote:
AT>[...]
AT>> I wonder how one would implement a per-thread current directory
AT>> in an environment where there is no 1:1 mapping between user
AT>> threads and kernel threads.
AT>
AT>Something similar to (but probably a bit less convoluted ;-) )
AT>a per-thread signal mask, I guess.
AT>
AT>> While I could think of ways, they seem too convoluted to me.

Given that I have only one per-process current working directory this
would force me to intercept all systemcalls that contain pathnames and
fiddle with these, doesn't it?

Yes, very likely, if you insisted on doing this on a kernel that's not designed to support it. Of course you'd also need to synchronize your kernel threads to be sure that only one could hit such a point at any time since you can have only one process kernel state at a time.

This doesn't really even have anything to do with whether you've got 1:1 or M:N mapping of threads. If your kernel has a CWD per process and you're trying to make it per-thread, you're in trouble.

But there's nothing unique about this. If you want to have multiple threads within a process then each needs its own registers, including stack and instruction pointers. In POSIX, each has its own signal mask. If you want each to have its own "security persona", you need to store that. If each has its own CWD, you need to store that, too. To do M:N you either need to explicitly context switch each piece of data (expensive when they're kernel state), or you need abstracted user-managed contexts. In our case, the kernel gets "all this stuff" through the thread register. Adding a per-thread CWD would be a trivial matter of adding the field to the "shared area".

--
/--------------------[ yyyyyyyyyyyyyy@xxxxxx ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/


<Prev in Thread] Current Thread [Next in Thread>