>
> Or, you could simply write your threaded applications to always pass
> fully rooted paths. Seems like a much simpler change to me.
The performance of such an application will, of course, be significantly
worse than one which used per-thread or per-context current working
directories due to the need to traverse the full pathname on each
pathname-based operation, even with aggressive DNLC caching by the
operating system.
While chroot() was pulled from SUSv3, most implementations still
support it, and whilst I can't imagine a useful application where
different threads within the same process have different root
directories, I suspect someone else can.
(Many kernel implementations will have a per-thread working directory
even to support the current SUSv3 semantics simply to avoid having the
current working directory change while another thread is in the middle
of a kernel system call).
scott
>
> -----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.
>
>
|