1.30.0 - problem with filesystem lib
Hi,
When using the filesystem lib in the 1.30.0 release, I experience hangs
when incrementing the directory iterator.
The compiler I've been using is MinGW, an example that exhibits the
behaviour on my machine is included below.
The hang only occurs when -mthreads is used.
The hang occurs on the increment when there are no more files in the
directory.
Russ
// -------------------------------------------------------- cut
#include
Russ Wood wrote:
Hi,
When using the filesystem lib in the 1.30.0 release, I experience hangs when incrementing the directory iterator.
The compiler I've been using is MinGW, an example that exhibits the behaviour on my machine is included below.
The hang only occurs when -mthreads is used.
The hang occurs on the increment when there are no more files in the directory.
I had the same problem with C++Builder 6 when first using the filesystem library. The default builds for filesystem are single threaded. If your application is multi-threaded, then you need to re-build the filesystem library with multi-threading (it uses mutexes somewhere (I think from smart_ptr but can't remember)). If you use the single-threaded library, then you don't get the mutex, but the ++operator is inlined and tries to lock it. This causes a hang as the win32 light-weight mutex is stored as just an integer (long maybe), so the program just hangs waiting for it to be cleared. I have built four versions of the library libboost_filesystem.lib - release, single-threaded libboost_filesystemd.lib - debug, single-threaded libboost_filesystemmt.lib - release, multi-threaded libboost_filesystemmtd.lib - debug, multi-threaded I use a #pragma int the code to link the appropriate lib depending on Borland's __MT__ define (and also if I want debugging or not) HTH Russell
On Fri, 21 Mar 2003, Russell Hind wrote:
I had the same problem with C++Builder 6 when first using the filesystem library. The default builds for filesystem are single threaded. If your application is multi-threaded, then you need to re-build the filesystem library with multi-threading (it uses mutexes somewhere (I think from smart_ptr but can't remember)). If you use the single-threaded library, then you don't get the mutex, but the ++operator is inlined and tries to lock it. This causes a hang as the win32 light-weight mutex is stored as just an integer (long maybe), so the program just hangs waiting for it to be cleared.
I have built four versions of the library
libboost_filesystem.lib - release, single-threaded libboost_filesystemd.lib - debug, single-threaded libboost_filesystemmt.lib - release, multi-threaded libboost_filesystemmtd.lib - debug, multi-threaded
I use a #pragma int the code to link the appropriate lib depending on Borland's __MT__ define (and also if I want debugging or not)
HTH
Russell
That makes sense, thanks. It would be good if all four versions were built by bjam, or if this was mentioned somewhere in the docs. I wonder why it was decided to have locking on directory iterators at all, seems a bit low level? Thanks for your help Russ
Russ Wood wrote:
I wonder why it was decided to have locking on directory iterators at all, seems a bit low level?
AFAIK, there isn't explicit locking on directory iterators, but part of them uses a shared_ptr which if multi-threading is turned on, will mutex the increasing of the reference count. Some code that does this is inbuilt into the library, some gets inlines in your code, therefore differences can occour. Another way around this is to link with the filesystem source .cpps directly. That way they are built with your current compiler setttings Cheers Russell
Russell Hind wrote:
I had the same problem with C++Builder 6 when first using the filesystem library. The default builds for filesystem are single threaded. If your application is multi-threaded, then you need to re-build the filesystem library with multi-threading
I have put a quick comment to this effect on the boost Wiki (in the Common Build Problems section) I'm not sure this is the correct place for all platform-dependant problems, but is the best I could spot for now. --- AlisdairM
participants (3)
-
Alisdair Meredith -
Russ Wood -
Russell Hind