initial_path is not thread-safe

[Andrey Semashev]

The initial_path template function uses function-local static variable and thus is not thread-safe.

The documentation states the recommendadion to call initial_path from the beginning of the main function. However, following it is not sufficient because:

1. If the application consists of several modules (dll or so), on many architectures each module will contain its own copy of the static variable defined in initial_path. Each copy will be initialized as needed, when initial_path is called from within the corresponding module.

2. The threads may already be running when initial_path is called. This may be true regardless of whether initial_path is called from main or some another place in a dll.

What makes the problem worse is that there are two such functions, actually: initial_path< path >() and initial_path< wpath >(). Each of them will have the described problem.

[Andrey Semashev]

The suggested solution would be to create a single global variable in the Boost.Filesystem dll, and initialize it of the application startup. On platforms that do not syncronize threads during dll loading (are there any?) one could use call_once from Boost.Thread and initialize it similarly (on the application startup).

[Beman Dawes]

initial_path() has been deprecated in version 3.

--Beman

[Andrey Semashev]

1. In v.3 the function "complete" uses detail::initial_path which is still not thread-safe.
2. I don't see the reason for removal of this function.