| To: | "Kaz Kylheku" <yyy@xxxxxxxxxxxxxxxxxxx>, "Alexander Terekhov" <yyyyyyyy@xxxxxxxxxx> |
|---|---|
| Subject: | RE: thread-private working directory |
| From: | "Jason Zions" <yyyyyyyy@xxxxxxxxxxxxxxxxxxx> |
| Date: | Mon, 4 Aug 2003 11:23:34 -0700 |
| Cc: | <yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx>, <yyyyyyyyyyyyyy@xxxxxxxxxxxxx> |
| Thread-index: | AcNYSvLD0Sih9KhrQ8mUfKvCwc+2zwCaiPVw |
| Thread-topic: | thread-private working directory |
Or, you could simply write your threaded applications to always pass fully rooted paths. Seems like a much simpler change to me. -----Original Message----- From: Kaz Kylheku [mailto:yyy@xxxxxxxxxxxxxx] On Behalf Of Kaz Kylheku Sent: Friday, August 01, 2003 9:19 AM To: Alexander Terekhov Cc: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx; yyyyyyyyyyyyyy@xxxxxxxxxxxxx Subject: Re: thread-private working directory On Fri, 1 Aug 2003, Alexander Terekhov wrote: > Harti Brandt wrote: > [...] > > I wonder how one would implement a per-thread current directory in > > an environment where there is no 1:1 mapping between user threads > > and kernel threads. > > Something similar to (but probably a bit less convoluted ;-) ) a > per-thread signal mask, I guess. What you can do is make the system calls take an extra parameter: a context token designating the current directory relative to which paths are to be resolved. The user space can then associate these tokens with schedulable entitites. They are not visible through the library interface, which makes the contexts implicit. |
| Previous by Date: | Possible areas for revision, Andrew Josey |
|---|---|
| Next by Date: | Re: thread-private working directory, s lurndal |
| Previous by Thread: | Re: thread-private working directory, Kaz Kylheku |
| Next by Thread: | Re: thread-private working directory, Kaz Kylheku |
| Indexes: | [Date] [Thread] [All Lists] |