Software Layout (Multithreading, QWorkspace, Fileoperations)

[Daedalus]

Hi all,
not sure where to post this, so I'll put it in the Newbie-Section.

I'm currently stuck at a general software layout without a clue about the best way to handle this:
What I got is a QWorkspace inside the MainWindow and a QDockWidget displaying user names. If a user is clicked, a separate Widget is opened in the Workspace, displaying a loading-screen and an icon in front of the User shows the state 'Loading'. So far, so good...
What I try to achieve is, if the loading screen is displayed, a corresponding logfile is opened and transferred into a QTableView with a SortProxyModel. The filesize can be up to 100 Mb, maybe more. After processing, the Icon shows the state 'Opened'. In theory, all users could be processed simultaneously. That is, where my problem arises.

I tried to put processing in a Qthread, that has the Widget with the loading screen as its parent. If I close the loading-screen, end the thread with exit() and catch finished() to set the state back to 'Closed', the thread my be processed on and after reset sets the state to 'Opened' again. I don't like the idea of using terminate() because of locked mutexes and opened file-handles. Furthermore, a wait()-call blocks the whole GUI (and so the other opened userfiles).

another idea would be, to put the displaying widget also in a thread, but then...is it possible to put the contained TableView to the workspace with addWindow?

I'm a bit lost, how to best design these two processes. Maybe someone can give me a hint, how to start on this problem.

Thanks in Advance,
Daedalus

[high_flyer]

I tried to put processing in a Qthread, that has the Widget with the loading screen as its parent.
In general this is the way I would do it, spiliting the (possible) parallel work in a thread.

Furthermore, a wait()-call blocks the whole GUI (and so the other opened userfiles).
I am not sure I follow.
From this it sounds, as if each thread you open will open a new dialog.
This might make sence (though I am still not quite sure how) if your application is a netwrok server.
But then the clients are the ones opening their own dilalog for each job, not the server.
So, I am not sure what you said here.
Furthermore, the whole idea to put the working thread in its own thread is also to separate it from the GUI thread.
So if your GUI thread waits for the working thread, you don't need a separate thread, since its not parallel, but sequencial work.
But I probably understood you wrong.
Maybe on hand of my post you could clarify a bit more.

[Daedalus]

To give a bit more background:

Some software writes all clients to a csv file. Then creates a subdir with clients name and puts a logfile there (also csv-based). I'd like my application to be able to open a single TableView for each of these logfiles in the workspace.

So for every selected client, a new analysis-widget will be opened and filled from the corresponding logfile .

I hope, this explains the purpose somewhat better.

[wysota]

You could do it without threads at all... If you process files chunk by chunk, you can iterate all open files and do everything without blocking the GUI for too long.

[Daedalus]

It turned out, that I need an importer-thread, because the files may be quite large( processing takes about one minute for a 75MB file, but time is not a vital factor here). But wysota's chunk-hint gave me the idea of simply checking an "abort"-Variable and taking all necessary measures, before calling exit(), resp. terminate() if it turns out to be needed, after every processed chunk of data.

Seems to work, thanks :)