Chdir and threads

SDL Development
1

hi i was wondering if i did a chdir in a thread created with
SDL_CreateThread, does that change the directory for all other threads as
well as the main one?

or does each thread have it’s own current directory?

Or is that OS specific?

Thanks!
Atrix

2

Alan Wolfe wrote:

hi i was wondering if i did a chdir in a thread created with
SDL_CreateThread, does that change the directory for all other threads as
well as the main one?

or does each thread have it’s own current directory?

Or is that OS specific?

It could be, but I suspect it’s not… chdir() is process-specific, not
thread-specific.

If memory serves, I think POSIX 1003.1 defined a chdir_r() that was
per-thread, but I might be hallucinating that.–
Chris Herborth (@Chris_Herborth)
Potestatem Obscuri Lateris nescitis

3

ahh…thanks for the info (:> ----- Original Message -----

From: chrish@pobox.com (Chris Herborth)
To:
Sent: Thursday, March 18, 2004 4:32 AM
Subject: Re: [sdl-lists] [SDL] chdir and threads

Alan Wolfe wrote:

hi i was wondering if i did a chdir in a thread created with
SDL_CreateThread, does that change the directory for all other threads
as

well as the main one?

or does each thread have it’s own current directory?

Or is that OS specific?

It could be, but I suspect it’s not… chdir() is process-specific, not
thread-specific.

If memory serves, I think POSIX 1003.1 defined a chdir_r() that was
per-thread, but I might be hallucinating that.

–
Chris Herborth (chrish at pobox.com)
Potestatem Obscuri Lateris nescitis

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

Alan Wolfe wrote:> ahh…thanks for the info (:

----- Original Message -----
From: “Chris Herborth”
To:
Sent: Thursday, March 18, 2004 4:32 AM
Subject: Re: [sdl-lists] [SDL] chdir and threads

Alan Wolfe wrote:

hi i was wondering if i did a chdir in a thread created with
SDL_CreateThread, does that change the directory for all other threads

as

well as the main one?

or does each thread have it’s own current directory?

Or is that OS specific?

It could be, but I suspect it’s not… chdir() is process-specific, not
thread-specific.

If memory serves, I think POSIX 1003.1 defined a chdir_r() that was
per-thread, but I might be hallucinating that.

It seems you are actually hallucinating :wink: btw, on all questions about
posix just google for +opengroup to see the standard
page from the unix group. All acting unix-compatibles should be
atleast on unix98 level. But I can’t see much of a thread-level chdir
even in 2003 specs.

as for the original question…

From my own experience, a chdir() is always process-wise, never
thread-local. This adds on to the scheme that all threads share
the same file-descriptor table of the single process (this is a real
posix thing). The posix specs say also that multiple threads may
use file descriptors concurrently, making reads/writes atomic.

While this is posix, not all systems essentially need to have posix
level threads, each platform may have their own view on this thing.
I do know some systems that use a thing usually called LWP, i.e.
leightweight processes. Those are essentially threads that share
a lot of things in their process area but some per-process calls work
suddenly as being really lwp-local.

From my own experienece, the latter is especially true for things
like signal-handling (note pthread.h has its own signal-related calls)
suddenly being restricted to their calling thread. But I do not quite
remember an lwp variant with a chdir() being lwp-local.

after all however, one can hardly trust in anything around threads,
simply because not anything a “thread” is really a posix thread.
Most importantly, until recently the linux threads were not strictly
posix compatible (see NPTL). Keep that in mind as a warning.

have fun,
– guido http://zziplib.sf.net
P.S taken from http://kerneltrap.org/node/view/422 :

The thread library is designed to be binary compatible with the old
LinuxThreads implementation. This compatibility obviously has some
limitations. In places where the LinuxThreads implementation diverged
from the POSIX standard incompatibilities exist. Users of the old
library have been warned from day one that this day will come and code
which added work-arounds for the POSIX non-compliance better be
prepared to remove that code. The visible changes of the library
include:

    • The signal handling changes from per-thread signal handling to the
      POSIX process signal handling. This change will require changes in
      programs which exploit the non-conformance of the old implementation.

    One consequence of this is that SIGSTOP works on the process. Job control
    in the shell and stopping the whole process in a debugger work now.

    • getpid() now returns the same value in all threads
    • the exec functions are implemented correctly: the exec’ed process gets
      the PID of the process. The parent of the multi-threaded application
      is only notified when the exec’ed process terminates.
    • thread handlers registered with pthread_atfork are not anymore run
      if vfork is used. This isn’t required by the standard (which does
      not define vfork) and all which is allowed in the child is calling
      exit() or an exec function. A user of vfork better knows what s/he
      does.
    • libpthread should now be much more resistant to linking problems: even
      if the application doesn’t list libpthread as a direct dependency
      functions which are extended by libpthread should work correctly.
    • no manager thread
    • inter-process mutex, read-write lock, conditional variable, and barrier
      implementations are available
    • the pthread_kill_other_threads_np function is not available. It was
      needed to work around the broken signal handling. If somebody shows
      some existing code which makes legitimate use of this function we
      might add it back.
    • requires a kernel with the threading capabilities of Linux 2.5.36.