< Reply-To: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx >
Kaz Kylheku wrote:
[...]
> I think that if you have one thread doing things like open()
> calls with relative paths, and another one calls chdir(), all
> bets are off, what do you think?
I think that the process-wide working directory just ought to be
declared ``as thread safe as an int.'' IOW, concurrent read-only
usage shall be okay as long as all mutations are synchronized out,
so to speak. ("see XBD 4.10 for details" ;-) ). The same goes for
other things like stdio streams but, unfortunately, it's a bit too
late, I'm afraid.
[...]
> Any chdir's not surrounded in a push/pop would just affect
> the process-wide one.
Push/pop ala thread cleanup handlers? I mean: "The application
shall ensure that they appear as statements, and in pairs within
the same lexical scope (that is, the pthread_cleanup_push() macro
may be thought to expand to a token list whose first token is '{'
with pthread_cleanup_pop() expanding to a token list whose last
token is the corresponding '}' )". Uhmm. I'd probably still want
to have something to activate use of the thread-private working
directory in some "common" routine. I like pthread_chdir(). ;-)
regards,
alexander.
--
"911: Get me your boss, this is the chief of police.
(Answering machine at SCO) Sorry no one's available to take your
call. Currently the management is busy deciding which company to
sue. If you would like to help, please leave your company name
and corporate information like annual turnover, etc. after you
hear the beep."
-- http://tinyurl.com/ihu2
Sent by: Kaz Kylheku <yyy@xxxxxxxxxxxxxx>
To: Alexander yyyyyyyyyyyyyyyyyyyy@xxxxx
cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: slashdot feedback on the TR
On Thu, 31 Jul 2003, Alexander Terekhov wrote:
> Kaz Kylheku wrote:
> [...]
> > chdir is not thread safe
>
> AFAIK, chdir is thread safe but "not really useful" without
> some sync. ;-)
Okay, if I do a chdir in two threads, we know that one of them will
win; the end result won't be an error or some half-baked location. We
could say that the chdir() update is atomic, which is a far cry from
thread-safe.
Or do we really know that? Where is it written that chdir() is memory
synchronizing: that a chdir() in one thread must eventually be visible
to another thread, and atomically so?
I think that if you have one thread doing things like open() calls with
relative paths, and another one calls chdir(), all bets are off, what
do you think?
In reality, we know that in typical implementations these are kernel
calls that manipulate kernel data, so there is synchronization at that
boundary.
> Cox could have proposed something like pthread_chdir() with
> a null pointer used as an "indicator" to switch back to the
> process wide thing (using it, I mean). Or whatever.
A nice interface would be something for a dynamically-scoped
current-working directory.
chdir_push("/go/here"); /* thread-specific, saves old location */
chdir("/go/elsewhere"); /* change thread-specific location, no save */
chdir_pop() /* restores old location */
Any chdir's not surrounded in a push/pop would just affect the
process-wide one.
At once you have a useful interface for threads, as well as for saving
and restoring around foreign library functions.
This resembles the action of dynamically-scoped variable in Common
Lisp.
(defvar *current-directory* "/") ;; global to all threads
;; LET will save and restore, and give us a thread-specific
;; variable binding in Lisp implementations that support threads!
(let ((*current-directory* "/go/here"))
;; All code called from here sees this thread-specific
;; binding of *current-directory*, not the global one.
;; Store a new value in binding:
(setf *current-directory* "/go/elsewhere"))
;; prior binding restored
|