SFML community forums

Help => System => Topic started by: zac on June 04, 2008, 12:31:02 pm

Title: Sf::Thread
Post by: zac on June 04, 2008, 12:31:02 pm

I am writing a little file shredding program (Linux and Windows).
The file shred class sets up a thread to do the work, while the main thread still should be able to display the main window (updating the status information and so on).

Now I am encountering a problem with threads:
Thread.Launch() does not even return before the shredding thread finished, though I even use Sleep() in the shredding function to force a task switch thus making other Threads possible to work. This is surely not the purpose of threads, is it?

I have often enough implemented threads by CreateThread in Windows to know it should be working (at least in Windows) like I planned...
The shredding functions are all working properly (in Windows I even reversed my own code to check if it works correctly).

Title: Sf::Thread
Post by: Laurent on June 04, 2008, 02:56:53 pm

Can you show your code ? Or a minimal example which reproduces the problem ?

I don't think there's such a huge bug in SFML threads.

Title: Sf::Thread
Post by: zac on June 04, 2008, 05:23:58 pm

A little piece of code?

Code: [Select]


secureDelete *newInstance = new secureDelete;
*newInstance = *this;
if(newInstancePtr)
{
*newInstancePtr = newInstance;
}
sf::Thread shredThread((shredPtr)(gutmann),newInstance);
shredThread.Launch();
return true;

gutmann(secureDelete* newInstance) is the function I am calling. It works fine but the call shredThread.Launch() does not return before the shredding operation has finished.

I tried to use different priorities (a feature that would be nice in sf::Thread), but even with parent-priority 15 and child priority 0 it did not work...
I dont think it is a bug, I think this is because Linux uses kind of globally I/O block preventing the whole process and all of its threads to execute code while in I/O operations.
This is a difference between Linux and Windows.
I am just wondering if there is a possibility to turn this off.
If you want to experience this problem first-hand you could try to write some 100 Megs into a file using a thread to perform the operation (on Linux platform).
Using unbuffered, direct IO (like a shredder HAS to do, thus avoiding the risk that a file might be only once overwritten by buffering) increases the problem.

Title: Sf::Thread
Post by: Laurent on June 05, 2008, 11:08:18 am

Can you show the code of the gutmann function ?