Am 08.09.2013 22:32, schrieb Tomas Hajny:
On Sun, September 8, 2013 19:32, Sven Barth wrote:
On 08.09.2013 14:17, Bart wrote:
On 9/8/13, Tomas Hajny <xhaj...@hajny.biz> wrote:
Why do you believe that ExpandFilename is not threadsafe (on Windows or
any other platform)?
..
The only platform specific part inside
ExpandFilename is a call to GetDir function retrieving the current
directory. If that is not 'threadsafe' by itself (on Windows), then
your
statement is correct,
And that is exactly the point.
GetDir calls GetCurentDirectory and MS says (see:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364934%28v=vs.85%29.aspx)
that multithreaded applications should not call GetCurrentDirectory.
The problem is not GetCurrentDirectory itself (this function and
SetCurrentDirectory use the process's PEB lock to access the current
directory which is stored inside the PEB as well), but that different
threads could call SetCurrentDirectory with different values and thus a
thread who expected the current directory to be a specific one might
resolve a relative path (by using another WinAPI function) using a
current directory set by a different thread.
I believe that there are three different things:
1) We have a sequence in GetDir implementation for Windows targets which
changes the current directory. While this is obviously necessary due to
limitations of the respective Win32/64 API for retrieving current
directory combined with characteristics of the supported path names, it
may not be expected by the programmers who may have no call to
SetCurrentDirectory within their code and thus expect no issues with
thread safety. I don't know if it is possible to use a critical section or
something like that to avoid switching to another thread during this
context, but it might be useful to think about it in my opinion.
On Windows this is completely useless. A process has only *one* current
directory. The current-directory-per-drive ones are only implemented
inside the command line interpreter and other programs that use the crt
library (not to be confused with the crt unit). So the calling of
SetCurrentDirectory inside ExpandFilename is not only not threadsafe,
but doesn't result in something useful either!
2) Restrictions of Win32/64 API (relative paths not supported for long
paths) which will require a decision how to deal with this fact in FPC RTL
- basically, either find a "safe" way for expanding the relative paths to
absolute ones before calling the Win32/64 API with the long paths, or
decide not to support these long paths in the cross-platform RTL functions
(i.e. leave it up to the programmers to use the Win32/64 functions
themselves when requiring support for such long paths in their programs).
Feedback of others would be good here to decide how to proceed...
3) Programmers changing the current directory in their own code possibly
leading to unexpected behaviour (unexpected by the respective
programmers). I certainly wouldn't try to solve this one since that for
sure cannot be solved on our side.
Agreed.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
