On Fri, 1 Aug 2003, Alexander Terekhov wrote:
AT>< Reply-To: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx >
AT>
AT>Kaz Kylheku wrote:
AT>[...]
AT>> I think that if you have one thread doing things like open()
AT>> calls with relative paths, and another one calls chdir(), all
AT>> bets are off, what do you think?
AT>
AT>I think that the process-wide working directory just ought to be
AT>declared ``as thread safe as an int.'' IOW, concurrent read-only
AT>usage shall be okay as long as all mutations are synchronized out,
AT>so to speak. ("see XBD 4.10 for details" ;-) ). The same goes for
AT>other things like stdio streams but, unfortunately, it's a bit too
AT>late, I'm afraid.
AT>
AT>[...]
AT>> Any chdir's not surrounded in a push/pop would just affect
AT>> the process-wide one.
AT>
AT>Push/pop ala thread cleanup handlers? I mean: "The application
AT>shall ensure that they appear as statements, and in pairs within
AT>the same lexical scope (that is, the pthread_cleanup_push() macro
AT>may be thought to expand to a token list whose first token is '{'
AT>with pthread_cleanup_pop() expanding to a token list whose last
AT>token is the corresponding '}' )". Uhmm. I'd probably still want
AT>to have something to activate use of the thread-private working
AT>directory in some "common" routine. I like pthread_chdir(). ;-)
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. While I could think of ways, they seem too convoluted to
me.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
yyyyyy@xxxxxxxxxxxxxxxxxxx, yyyyy@xxxxxxxxxxx
|