Why not just merge the file parts when you are finished? You can write the parts to a QFile
easily. Perhaps something about the approach or the data keeps you from doing this, but if you can, it's probably the approach I would take before dealing with treating a QFile
as a shared resource.
If you want multiple concurrent replies to be able to write to and access the QFile
, then yes, the QFile
becomes a shared resource. As far as I know, you're going to need to lock it. At that point, you have several options. You can have the slot(s) handling the replies attempt to acquire a QSemaphore
, you can use QMutex
and QMutexLocker
if you'd prefer to lock on a mutex. You could treat it as a multiple producer (the various QNetworkReplys) single consumer (whatever is writing to the file) problem (here's a Stack Overflow post that provides some useful links) if you want to go that route. In short, there are numerous approaches here, all of which I think are more of a hassle than simply merging the file.part
's at the end if you're able to go that route.
In terms of merging to a single QFile
concurrently, there may be an easier Qt way of doing it, but I've never found it. Perhaps someone else can chime in if such a method exists.
I'm not sure what you mean by "which is the best way to save data in my application?" Are you referring to saving application specific settings in a persistent manner? If so, look into QSettings
. If you're referring to saving the data you're downloading, I'd probably write it to a QFile
, just like you appear to be doing. Although it's hard to know for sure without knowing more about what you're downloading.