Solved Diagnosing problem.
-
@SPlatten
You can certainly use @mchinand'sQLockFile
, and that looks like the most "Qt" solution. I just don't like that it requires a separate file to lock.Or you can do it as we (I) did before Qt. When one process wants to write its bytes to the file you use a C/C++ library call (like Linux
lockf()
, MSVC_locking()
) on the file handle (QFile::handle()
) to lock all bytes in the file (waits if other process has it locked), write bytes, release lock; other process does the same. Does the exclusivity "in-file", but at the expense of platform-dependent call. -
This post is deleted! -
This post is deleted! -
Sorry people, I think I was misleading in my original post. Only the main application writes to the file the other applications send back the JSON via a socket to the main application and its this that writes to the file , so no file locking is required.
However there is still a problem with the output which I am investigating.
-
@SPlatten
If output is interleaved from within one application, are you sure you are not using multiple threads to write to the file...? -
@SPlatten your „void clsDebugService::process()“ is not reentrant save, but you call processevents in it, potentially allowing it de be excuted multiple times, jumping back and forth etc.
probably the issue of strange jumbled output.
-
@J-Hilk , thank you, I will take a look into this. To the process function I've added:
static bool blnProcessingEvents(false); QString strData; while ( true ) { if ( blnProcessingEvents == false ) { blnProcessingEvents = true; //Prevent recursion QCoreApplication::processEvents(); blnProcessingEvents = false; }
Just tested, results are still the same in the output file:
Client connected !s1!Cli:mdSQL:s1:ent connecting... !f1!Cli:mdFIO:f1:ent connecting... !x1!Cli:mdXML:x1:ent connecting... !s1!Cli:mdSQL:s1:ent connected !f1!Cli:mdFIO:f1:ent connected !x1!Cli:mdXML:x1:ent connected
Where the prefix !s1!, !f1! and !x1! are module alias, the message is supposed to read Client connecting... but it always has text inserted into it, which is very confusing.
-
Do not call QCoreApplication::processEvents() inside the Qt message handler. It will just create problems (you can see the easiest by yourself).
-
@Christian-Ehrlicher , I've commented out the call to QCoreApplication::processEvents();, still getting the same problem.
-
In the end after cleaning up the code and removing calls to processEvents the actual fault was caused by something quite simple in the string formatting logic.
-
@SPlatten
great you found the solutionnevertheless this
cleaning up the code and removing calls to processEvents
is never a bad thing to do :D