How to disconnect signal/slot?

[arcull]

Thank you both for suggestions. It was my fault, I called function RedirectOutput with 0 at the beginning and RedirectOutput with 1 at the end of external library call, but this way I had different "watcher" created 2 times.

QFileSystemWatcher * watcher = new QFileSystemWatcher(this);

QFileSystemWatcher * watcher = new QFileSystemWatcher(this);

To copy to clipboard, switch view to plain text mode 

I solved this, so the signal-slot gets disconnected, but now I have a bigger problem. It looks like the external lib function call executes so fast that signals don't fire in time, or the thing runs asynchronously. So it looks like, I disconnect signal-slot before the signals arrive. I figured out this by adding some custom marks to my textEdit and watched the sequence how they got appended. Here is some pseudo code

put redirect to file & connect signal-slot
execute external lib code
get output back to screen and disconnect signal-slot

put redirect to file & connect signal-slot
execute external lib code
get output back to screen and disconnect signal-slot

To copy to clipboard, switch view to plain text mode 

I can post entire code if necessary. Do you have any suggestion how could I solve this. I'm banging my head against the wall the entire afternoon with this, so any idea much appreciated.

[yeye_olive]

You cannot rely on QFileSystemWatcher to keep you informed of all changes to the file in a timely manner. With your current architecture, perhaps you should inspect the file one last time before you delete it, and catch any output not reported by the watcher.

There are alternatives, but I am afraid they are platform-specific.

Under a POSIX system, you can call open_memstream() to open a growable memory stream and try to assign the resulting stream to stdin (but that may not work as stdin is not guaranteed to be assignable), but you will need to poll the stream regularly to get its contents.

Alternatively, you may use pipe() and dup2() to redirect the underlying stdout file descriptor to a pipe, and use QSocketNotifier to get notifications whenever data arrives in the pipe. Beware of deadlocks though: printf() in the library will block whenever the pipe's buffer is full, so it is vital that the QSocketNotifier live in another thread whose job is to:

1. quickly read from the pipe,
2. decode the bytes with a stateful decoder (QTextDecoder) into a growable QString,
3. emit a signal to notify the GUI thread that data is available,
4. NEVER write anything to stdout!

When the main GUI returns to its event loop and picks up the signal, it can consume the contents of the QString and append them to the display widget.

I see no way around the asynchrony of these solutions: you have no way to execute arbitrary code (like appending text to a display widget) in the middle of a printf() call by the library. Arguably it would be much easier if your library lived in another process or had alternative ways to log its output.

[arcull]

thanks yeye_olive, the solution you describe looks a bit complicated for my current level of knowledge in c++ and qt, however the idea of having a second thread for invoking external lib would probably be simpler or at least better, I've done something like that once in Java, but I have to refresh/check how the principle how that works. One question though: if I redirect display of stdout to file in second thread, do I still have normal stdout in first (main) thread? Much thanks again.

[yeye_olive]

thanks yeye_olive, the solution you describe looks a bit complicated for my current level of knowledge in c++ and qt, however the idea of having a second thread for invoking external lib would probably be simpler or at least better, I've done something like that once in Java, but I have to refresh/check how the principle how that works.

Actually the solution I outlined in my previous post assumed that the library calls were executed in the main (GUI) thread; the other thread is only needed to read from the pipe while the library writes to it through stdout. The thread does not even need to be visible outside of the logging mechanism.

if I redirect display of stdout to file in second thread, do I still have normal stdout in first (main) thread?

Unfortunately, the answer is no. stdout is a process-wide stream. It would be great if the library were able to write to a custom logger instead of stdout; you could then implement a logger that would append the text to your widget. If you need a separate stdout for the rest of your program, then I am afraid your only option is to spawn a process that will execute the library calls on your behalf.

[arcull]

thanks yeye_olive. Well I have to consider how much gain do I get with how much trouble. The point is that the external lib uses pritfs when you invoke it's functions and since I have a gui app, I could leave the stdout redirection to file active the whole time, just for the purpose of external lib. If I want to print out something to the qui interface like textEdit, I don't really need printfs. I mean I can avoid the print to stdout from my main app, I can use textEdit->append and similar methods. Or am I missing something here? Thanks for your help.

[anda_skoa]

Depending on what kind of data you need to transfer between your code and the library, one option could be to run the library in a helper program through QProcess.

Cheers,
_

[arcull]

thanks anda_skoa, but I'm not sure I understand what you mean by QProcess. Is this second thread approach? Please provide more info and how to intercept library string output this way? Type of data the library outputs is more or less just some strings explaining progress and results nothing more. Thanks.

[anda_skoa]

Not a thread, a separate process.

QProcess is Qt's facility for running other programs, it can write to the other programs stdin and read its stdout and stderr.

Depending on the data to the library it might be possible to create a small helper program that is run by the main application as a child process.

Cheers,
_

[arcull]

I've been tackling this issue a bit more and came to a conclusion, that in my case it is better not to use signal/slots at all. I've done it this way: whenever I need to call the external lib functions I first invoke my function which redirects stdout to a file, then call the function and afterwards call another my function which set stdout to normal, reads content of the redirection file and appends it to my textEdit. Thank you again all for you suggestions.