Using boost interprocess file_lock.timed_lock
Hello List, Could someone please give me a working example of how to use this please. I am obviously doing something wrong as depending on how much I write to the std::ofstream I either end up with a proper file or a file containing a single byte! I would really appreciate your assistance with this as it's driving me to distraction. Here is the approach I am taking. std::ofstream os ; os.open(m_FileName.c_str(), std::ios_base::out | std::ios_base::binary | std::ios_base::app) ; try { if (os.is_open()) { os.setf(std::ios::fixed, std::ios::floatfield) ; os.precision(3) ; if (fileLock.timed_lock(pt += pt::seconds(5))) { try { for (int o = 0; o < 48; o++) { os << "Write my data here....." ; for (int i = 0; i < 51) { os << i ; // But if I output this simple line and I get a 1 byte file and NO errors or exceptions! } } fileLock.unlock() ; } catch (std::ofstream::failure e) { qDebug() << e.what() ; } } else { qDebug() << "No lock on file!" ; } } else { qDebug() << "File not opened!" ; } } catch (ip::interprocess_exception& e) { qDebug() << e.what() ; } catch (std::exception& e) { qDebug() << e.what() ; } os.close(); -- Bill
On Mon, Jul 25, 2011 at 5:41 PM, Bill Moo <cppsysdev@gmail.com> wrote:
for (int o = 0; o < 48; o++) { os << "Write my data here....." ; for (int i = 0; i < 51) { os << i ; // But if I output this simple line and I get a 1 byte file and NO errors or exceptions! } }
i isn't incremented. What is o supposed to do? Colin
On Thu, Jul 28, 2011 at 2:53 PM, cc caprani <cc.caprani@gmail.com> wrote:
On Mon, Jul 25, 2011 at 5:41 PM, Bill Moo <cppsysdev@gmail.com> wrote:
for (int o = 0; o < 48; o++) { os << "Write my data here....." ; for (int i = 0; i < 51; i++) { os << i ; // But if I output this simple line and I get a 1 byte file and NO errors or exceptions! } }
i isn't incremented. What is o supposed to do?
Well spotted Colin thank you for taking the time to reply, but in my real code i was incremented. I supplied this pseudo code to demonstrate how I was using the library just in case my usage was incorrect. Of course in the real code if i wasn't incremented then I would never exit the loop so I would not get my file, regardless of its size. I simply can understand why this doesn't work. I am using 64 bit builds of Qt v4.7.2, boost v1.46.1 and using the the Intel compiler v12.0.1029.2010 on Windows 7 SP1 x64 Any help on this would really be appreciated. -- Bill
Well spotted Colin thank you for taking the time to reply, but in my real code i was incremented. I supplied this pseudo code to demonstrate how I was using the library just in case my usage was incorrect. Have you missed maybe an *other* important detail in your pseudocode? If you really want help, provide small working example demonstrating your problem. Try it with reference compiler (msvc/gcc) to make sure it is not a compiler issue.
I simply can understand why this doesn't work. I am using 64 bit builds of Don't hurry
On Fri, Jul 29, 2011 at 8:42 AM, <Viatcheslav.Sysoltsev@h-d-gmbh.de> wrote:
Well spotted Colin thank you for taking the time to reply, but in my real
code i was incremented. I supplied this pseudo code to demonstrate how I was using the library just in case my usage was incorrect.
Have you missed maybe an *other* important detail in your pseudocode? If you really want help, provide small working example demonstrating your problem. Try it with reference compiler (msvc/gcc) to make sure it is not a compiler issue.
I simply can understand why this doesn't work. I am using 64 bit builds of
Don't hurry
Hi, I appreciate the example was useless and of course missing the timed_lock request, so apologies for wasting your time. I have now provided a complete example as requested, as a Win32 console app built in x64. However, I am unable to test on any compiler other the Intel as I do not have the applicable libraries, but I suspect this may not be a compiler issue. I suspect the real problem lies between the seat and the keyboard. Not to sure what you meant by "Don't hurry" but I suspect there may be an odour or urine in the air. #include "stdafx.h" #include <iostream> #include <fstream> #include <boost/date_time/posix_time/posix_time.hpp> #include <boost/interprocess/exceptions.hpp> #include <boost/interprocess/sync/file_lock.hpp> using namespace boost::interprocess ; using namespace boost::posix_time ; int _tmain(int argc, _TCHAR* argv[]) { std::string m_FileName("./locktest.txt") ; std::ofstream os ; os.open(m_FileName.c_str(), std::ios_base::out | std::ios_base::binary | std::ios_base::app) ; try { if (os.is_open()) { file_lock fileLock(m_FileName.c_str()) ; ptime pt(second_clock::local_time()) ; os.setf(std::ios::fixed, std::ios::floatfield) ; os.precision(3) ; if (fileLock.timed_lock(pt += seconds(5))) { try { // Do rows for (int o = 0; o < 48; o++) { os << "This is row " << o << " of 48" << " and this is just text" << "\n" ; // Do columns for (int i = 0; i < 51; i++) { os << i << "\t" ; } } fileLock.unlock() ; } catch (interprocess_exception& e) { std::cout << e.what() ; } catch (std::ofstream::failure e) { std::cout << e.what() ; } } else { std::cout << "No lock on file!" ; } os.close() ; } else { std::cout << "File not opened!" ; } } catch (std::exception& e) { std::cout << e.what() ; } std::cout << "Press a key to close." ; std::cin.get() ; return 0 ; } Thank you. -- Bill
El 30/07/2011 9:58, Bill Moo escribió:
On Fri, Jul 29, 2011 at 8:42 AM, <Viatcheslav.Sysoltsev@h-d-gmbh.de <mailto:Viatcheslav.Sysoltsev@h-d-gmbh.de>> wrote:
This is a Boost.Interprocess bug that I don't think it can be easily solved. Once you lock a file in Windows, you can only write to it through the handle (internal to fileLock) used to lock it. That's why the handle inside "os" is blocked. I should note this in the documentation as file locking can only be used portably in Interprocess to control access to ANOTHER file (or resource) but not to limit access to the same file you've just locked. From MSDN: http://msdn.microsoft.com/en-us/library/aa365203%28v=vs.85%29.aspx "Locking a region of a file is used to acquire shared or exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region." Best, Ion
2011/7/30 Ion Gaztañaga <igaztanaga@gmail.com>
El 30/07/2011 9:58, Bill Moo escribió:
On Fri, Jul 29, 2011 at 8:42 AM, <Viatcheslav.Sysoltsev@h-d-**gmbh.de<Viatcheslav.Sysoltsev@h-d-gmbh.de> <mailto:Viatcheslav.Sysoltsev@**h-d-gmbh.de<Viatcheslav.Sysoltsev@h-d-gmbh.de>>> wrote:
This is a Boost.Interprocess bug that I don't think it can be easily solved. Once you lock a file in Windows, you can only write to it through the handle (internal to fileLock) used to lock it. That's why the handle inside "os" is blocked. I should note this in the documentation as file locking can only be used portably in Interprocess to control access to ANOTHER file (or resource) but not to limit access to the same file you've just locked. From MSDN:
"Locking a region of a file is used to acquire shared or exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region."
Best,
Hi Ion, Ah! It wasn't me I'm glad to hear that, and thank you very much for the informative reply. I will just have to think of another approach to this. Thank you again for your time. -- Bill
participants (4)
-
Bill Moo -
cc caprani -
Ion Gaztañaga -
Viatcheslav.Sysoltsev＠h-d-gmbh.de