Am Montag, 18. November 2013 um 21:27:58, schrieb Georg Baum <georg.b...@post.rwth-aachen.de> > Kornel Benko wrote: > > > Hi, > > can we please have some locking mechanism here? > > This would indeed be a good idea. > > > While parallel export testing is OK, if the userdir is configured, > > it is not if started with a fresh created userdir. > > > > I have a patch implementing it. While this works for me, I am unsure, > > if this is the right c++ way, or if this is platform independent. > > It is not. I would believe that qt has a solution, but a quick search found > only http://doc.qt.digia.com/solutions/3/qtlockedfile/qtlockedfile.html > which is not part of qt. I don't know if QMutex synchronizes only between > threads or also between processes. If it does the latter, you could also use > Mutex::Locker from support/mutex.h instead of a file. As a last resort, you > could use your implementation for unix/os x and a windows implementation > using CreateFile() with dwShareMode=0 (see http://msdn.microsoft.com/en- > us/library/aa363858.aspx). This would of course go to support/os. > > > Originally I wanted to use > > string const lock_file = > > addName(package().user_support().absFileName(),".lock") but the problem > > here is, that the userdir may not be already created. > > So why not simply construct a name at the same level as userdir, e.g. > package().user_support().absFileName() + ".lock"? >
Actually, good idea. Stupid me, I didn't think of it.
Still the question stays: Is it portable enough?
> Georg
Kornel
signature.asc
Description: This is a digitally signed message part.
