Am 09.09.2013 13:25, schrieb Sven Barth:
Am 08.09.2013 22:13, schrieb Mattias Gaertner:
On Sun, 08 Sep 2013 19:32:23 +0200
Sven Barth <pascaldra...@googlemail.com> 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)?
[...]
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.
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.
Actually the problem is that Windows has multiple current directories,
but you can only read the one of the active drive.
This. Is. Wrong.
MSDN remark for Set-/GetCurrentDirectory: Each process has a single
current directory that consists of two parts: ...
The current directory per drive is only for the command interpreter
and programs that use the crt library (not to be confused with our crt
unit).
Correction, there seems to be a bit more magic going on... I'll report back.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
