I have a call to an external program that opens a "modal" window, since it's in the same thread as the main loop it blocks redrawing of the underlying window.
The program runs as a separate process and I am communicating with the program via pipes.
From what I've read it's bad practice to have an additional main loop, so what is the correct way to avoid this lockup?
The question is how to make a separate thread in my own program to do the communication with that program without blocking the entire main loop.
Use a non blocking API to run the external program, such as GSubprocess https://developer.gnome.org/gio/stable/GSubprocess.html or the lower level spawn API https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html
You could also use a thread but the above APIs are much easier.
You have to somehow return control to the main loop while the subprocess runs, that's the bottom line.
Related
How can I write a main loop which blocks while waiting for messages from multiple sources? As I understand it, the preferred way of writing an event-processing loop is to have it block while waiting for events.
However, how can blocking be handled correctly when messages may come from multiple sources?
I would like to write a GTK GUI which responds both to user input events and to messages sent via nanomsg.
GTK allows its events to be handled by calling gtk_main() or, in a non-blocking way, with gtk_main_iteration_do (FALSE).
Nanomsg can receive a message in either blocking or non-blocking mode, as well as poll for messages.
Is it possible to somehow block until whichever source first has input available "unblocks"? I.e. is there an alternative to using sleep which remains responsive to all events?
You can have as many threads as you want in your GTK+ application (and you are not forced to use GMainLoop instances) provided that any call that modifies the UI happens in the main GTK+ loop.
In this answer I provided an example with 100 threads updating the same user interface.
At the end you can fork and use whatever you are more familiar with in your own thread (being it polling, blocking or whatever) and be careful only when you need to notify (i.e. modify the UI).
I'm porting an ancient VB6 program to C#/.Net. I don't know VB6 very well and I'm asking this to understand it better.
The old VB6 program had a main course of program execution, but it also had lots of event handlers either for socket events or for timer events and the handlers for these often manipulated shared resources, e.g., common global variables, whenever they woke up and ran.
Nonetheless the old program seemed to run OK.
Trying to do this same architecture in C# is disastrous because event handlers for the socket or timers are called by the system in different threads from the main application thread and result in frequent exceptions like "The calling thread cannot access this object because a different thread owns it.", not to mention more subtle problems. Most of my work in the conversion is re-architecting the program to make it thread-safe, and eliminating the original program's heavy use of global variables.
My question is Do VB6 event handlers run in separate threads? If so how did VB6 ever get away with this? Among other things, the VB6 program had a timer that woke up every 4 seconds, manipulated some global variables and went back to sleep, while the main program was doing its thing. I can't understand why this didn't result in collisions.
Apartment-Model Threading in Visual Basic
If you want the gritty details, research apartment threading models in COM. VB6 basically uses COM and it's built-in implicity threading models to treat single threads as message-passing entities. It simplifies thread-safety, but underneath you are sacrificing a lot of overhead by basically treating all method calls as queued service calls.
All of your code basically runs in a container that implements COM service calls. If you've ever worked with something written in VB6 in another language, you can interact with them via COM, usually.
Do VB6 event handlers run in separate threads?
Not really, because there aren't separate threads. Your code runs on a single thread, wrapped in the service-like architecture I described above. Most of what you talk to that is threaded is other COM objects which have their own apartments. So to communicate back and forth, you are basically doing RPC calls when the threads talk to each other: you aren't directly manipulating them.
Among other things, the VB6 program had a timer that woke up every 4 seconds, manipulated some global variables and went back to sleep, while the main program was doing its thing. I can't understand why this didn't result in collisions.
The "timer" is on a separate thread created for the timer, but when it calls into your code, you are guaranteed not to interrupt any other functions, because the function calls are basically queued one at a time in the thread.
My question is Do VB6 event handlers run in separate threads?
Common answer: No.
Real answer: Yes, if you make nasty Win32 calls to spawn more threads. The odds of doing this correctly are close to zero. I don't think I've ever seen it in real code.
Among other things, the VB6 program had a timer that woke up every 4 seconds, manipulated some global variables and went back to sleep, while the main program was doing its thing. I can't understand why this didn't result in collisions.
When the timer wakes up, it puts a message in the UI's queue. When the UI goes idle, it processes the message and runs the event on the UI thread.
You can do the same thing in WinForms if you use the right timer.
To Matt Wilko, DoEvents is VB6 implementing a virtual cooperative multithreading thing. What's a thread, something that can be interupted to run other code. When you use DoEvents you interupt the execution of your code, when the CPU does multithreading it preempts your code. The effect is the same. One done by VB6 runtime and one by the CPU.
The effect is the same. YOU NEED TO SYNCHRONISE ACCESS TO GLOBAL OBJECTS and VARIABLES.
Your event Handlers aren't supposed to run too long. Each event is queued and run one at a time.
Also the way to multithread a VB6 thing is to put other things in a COM Exe file with a asynchronous model. The exe calls back when finished.
After all the literature i've read on node.js I still come back to the question, does node.js itself make use of multiple threads under the hood? I think the answer is yes because if we use the simple asynch file read example something has to be doing the work to read the file but if the main event loop of node is not processing this work than that must mean there should be a POSIX thread running somewhere that takes care of the file reading and then upon completion places the call back in the event loop to be executed. So when we say Node.js runs in one thread do we actually mean that the event loop of node.js is only one thread? Or am i missing something here.....
To a Javascript program on node.js, there is only one thread.
If you're looking for technicalities, node.js is free to use threads to solve asynchronous I/O if the underlying operating system requires it.
The important thing is to never break the "there is only one thread" abstraction to the Javascript program. If there are more threads, all they can do is queue up work for the main thread in the Javascript program, they can never execute any Javascript code themselves.
I have two versions of a minimal web server.
Both execute an infinite loop that receives incoming requests and creates a thread to service each request.
One version simply starts executing that infinite loop.
The other version creates a special thread to execute the infinite loop, and the main program then drops into a standard Windows GetMessage/DispatchMessage loop.
Neither version has a GUI or a console window, they both simply run invisibly, and there's no mechanism coded to make the programs quit (ie, deliberately exit any of their loops).
Any guesses as to why one version uses the extra thread plus GetMessage/DispatchMessage?
It could be habit, based on the habits of the developers of the respective versions. Someone more accustomed to GUI coding might be more likely to add the GetMessage/DispatchMessage code. They may have started with a standard template and adjusted to create the specific project.
Or it could be deliberate -- maybe someone anticipated adding a GUI or some housekeeping tasks in the main thread. Or maybe a watchdog mechanism, where if the infinite loop were to crash (due to an uncaught exception, for instance) the main thread would automatically restart the loop.
I could be way off base, but the question does ask for guesses.
Main (function main is there) thread of my program is reserved for non-GUI tasks. It calls a number of lengthy calculation functions. All implemented GUI's have been doing their work in a separate threads.
I'm now going to implement one more GUI using Qt. Qt documentation says all GUI related tasks should be done in main thread.
In my case, inserting occasional QCoreApplication::processEvents() calls in main thread would be virtually useless due to great delays between them.
Is there any way to overcome this constraint of Qt?
Is it impossible to do something non-GUI related in main thread of Qt program?
No, you should be doing your calculations in a separate thread. As you already mentioned, there is a work-around available in QCoreApplication::processEvents(), but it sounds like you're unable to make that work for you.
If you don't want to have to do all the work of setting up a QThread and moving all your code, you may find that the QtConcurrent::run function is useful - it allows you to run a function asynchronously.
A few pointers: You should try and keep your main (GUI) thread as light as possible. Large amounts of IO or calculations should either be done asynchronously using QtConcurrent::run, or run inside a separate QThread. Depending on the complexity of your code, you may be able to get away with the QtConcurrent method.
It's best to offload the long computations onto other threads so the main GUI thread remains responsive. The old-school uniprocessing way of doing things would be be to make sure your computations never run for too long without polling GUI event handler, but that doesn't scale to multi-cores.
Fortunately Qt has excellent threading support. In the past you'd have to roll-you-own system for e.g farming out tasks to a thread-pool using QThread, QMutex, QWaitCondition etc, but recent Qt releases have made things easier with higher level abstractions like QThreadPool, QtConcurrent::run and QFuture.
I don't know how things will go if you call QApplication::exec() from another thread, which then becomes your gui thread. Just an idea.
(Let us know if it works, it'd be interesting...)
The concept of main thread is not clearly defined in Qt documentation. Actually, the main thread of a process (process that executes the Process.run function) can be different from the main Qt thread (thread that instantiates the first Qt object like a QApplication), although both "main" threads are often the same one.
Example of valid code structure:
function below will run in the process' non-main thread 'thread-1', that will become immediately Qt's main thread.
def startThread1():
app = QApplication(sys.argv)
app.exec_() # enter event loop
code below run in process' main thread, not to be confused with the main Qt and unique GUI thread of the process.
thread1 = Thread(target=self.startThread1)
thread1.start()
input('I am busy until you press enter')