Aborting a Boost.Thread
Hello, I am currently working on a filemanager for the Linux operating system, and I'm currently thinking about how to implement copying operations, such that 1. The GUI won't be blocked when operating on files 2. File operations can be cancelled at any time I thought about using Boost.Thread to run all the copy operations (which will be performed by Boost.Filesystem). However, I'm not quite sure how to handle this situation: Say copying a huge file, maybe 1GB+, is in progress. The progress will be displayed in a dialog window, as usual. Now the user decides that he wants to stop the copy operation, and clicks a cancel button. Now what do I do? The only means to terminate a thread that I know of is: 1. Killsignal it (I don't think boost supports it, since it's probably highly platform dependent) 2. Check for a terminate flag once in a while and return from the method once it is set. But how am I supposed to do the latter? The copy function doesn't return until it's finished right? So I can't check for a condition, because the copy-thread itself is blocked until it's done. I'm completely stuck here, help greatly appreciated. Cheers, Matthias -- Matthias Kaeppler
Matthias Kaeppler wrote:
Say copying a huge file, maybe 1GB+, is in progress. The progress will be displayed in a dialog window, as usual. Now the user decides that he wants to stop the copy operation, and clicks a cancel button.
Now what do I do? The only means to terminate a thread that I know of is: 1. Killsignal it (I don't think boost supports it, since it's probably highly platform dependent) 2. Check for a terminate flag once in a while and return from the method once it is set.
But how am I supposed to do the latter? The copy function doesn't return until it's finished right? So I can't check for a condition, because the copy-thread itself is blocked until it's done.
Well, if the 'copy' function does not return until it's completely done, then you won't be able to show progress indicator, right? And in order to show progress indicator, you need to copy files in chunks, so you'll have a natural place to check for the terminate flag. But generally, I think Boost is not the best tool for this task. For example, the KDE IO library allows you to request an io operator (like copy), and recieve progress indicator, and you can cancel the operation. Not to mention that it works with URLs, not just local files. Of course, KDE already has a file manager, but I assume you have your reasons for writing one. - Volodya
Vladimir Prus wrote:
But generally, I think Boost is not the best tool for this task. For example, the KDE IO library allows you to request an io operator (like copy), and recieve progress indicator, and you can cancel the operation.
Does GNOME have this, too? The FM is written with gtkmm.
Not to mention that it works with URLs, not just local files. Of course, KDE already has a file manager, but I assume you have your reasons for writing one.
I sure do. I have tried many (Konqueror, Krusader, gcommander, Xfe, XFFM, mc, rox-filer, ...), and I don't like any of em. So I thought I'd better write my own. -- Matthias Kaeppler
Matthias Kaeppler wrote:
Vladimir Prus wrote:
But generally, I think Boost is not the best tool for this task. For example, the KDE IO library allows you to request an io operator (like copy), and recieve progress indicator, and you can cancel the operation.
Does GNOME have this, too? The FM is written with gtkmm.
Something like: http://developer.gnome.org/doc/API/gnome-vfs/ But it's C and I have no idea if C++ wrapper is present or not.
Not to mention that it works with URLs, not just local files. Of course, KDE already has a file manager, but I assume you have your reasons for writing one.
I sure do. I have tried many (Konqueror, Krusader, gcommander, Xfe, XFFM, mc, rox-filer, ...), and I don't like any of em. So I thought I'd better write my own.
That's your call. - Volodya
Matthias Kaeppler wrote:
2. Check for a terminate flag once in a while and return from the method once it is set.
But how am I supposed to do the latter? The copy function doesn't return until it's finished right? So I can't check for a condition, because the copy-thread itself is blocked until it's done.
I think 2 is the way to go. However you need to think about your 'copy' operation... why do you have to copy the whole file in one function/system call? simply chop the file up into chunks and then it gives you a point at which to test the status of a condition variable, every 'X' bytes, you could even make 'X' user selectable, trading off throughput vs latency of handling the UI request. For free you then get to update your progress bar every so often too... Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
participants (3)
-
Kevin Wheatley -
Matthias Kaeppler -
Vladimir Prus