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. 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). 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. > So this can not be solved by using a lock inside ExpandFilename and > might happen on other systems as well as long as the current directory > is not stored per thread. Out of the 3 points above, the third one may obviously happen on any platform (and it should be the programmer's responsibility). The second one is obviously specific to Win32/64 API. The first one might exist for other platforms too, but I'm not aware of any particular one apart from Win32/64 (the pattern would be: support drives and/or volumes, allow paths to refer to current directory specific for that drive/volume, obviously also support multithreading, however do not allow querying the current directory on a specific drive/volume - e.g. OS/2 fits the first three conditions but not the last one, Unix platforms have no drives, Novell doesn't maintain current directory across different volumes and thus doesn't allow relative paths there as far as I know and DOS fits only the first two conditions). Tomas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
