It's a very common problem every developer faces every now and then, when visual updates may be so rapid and fast that it causes the contents of the form to flicker. I'm currently using a thread to search files and trigger an event to its calling (main VCL) thread to report each and every search result. If you've ever used the FindFirst / FindNext, or done any large loop for that matter which performs very fast and rapid iterations, then you would know that updating the GUI on every little iteration is extremely heavy, and nearly defeats the purpose of a thread, because the thread then becomes dependent on how fast the GUI can update (on each and every iteration inside the thread).
What I'm doing upon every event from the thread (there could be 100 events in 1 millisecond), is simply incrementing a global integer, to count the number of iterations. Then, I am displaying that number in a label on the main form. As you can imagine, rapid updates from the thread will cause this to flicker beyond control.
So what I would like to know is how to avoid this rapid flicker in the GUI when a thread is feeding events to it faster than it's able to update?
NOTE: I am using VCL Styles, so the flicker becomes even worse.
This is indeed a common problem, not always by threads, but by any loop which needs to update the GUI, and at the same time the loop is iterating faster than the GUI is able to update. The quick and easy solution to this is to use a Timer to update your GUI. Whenever the loop triggers an update, don't immediately update the GUI. Instead, set a some global variable (like the global iteration count) for each thing which may need to be updated (the label to display the count), and then make the timer do the GUI updates. Set the timer's interval for like 100-200 msec. This way, you control the GUI updates to only occur as frequent as you set the timer interval.
Another advantage to this is the performance of your thread will no longer depend on how fast your GUI can update. The thread can trigger its event and only increment this integer, and continue with its work. Keep in mind that you still must make sure you're thread-protecting your GUI. This is an art of its own which I will not cover and assume you already know.
NOTE: The more GUI updates you need to perform, the higher you may need to tweak the timer's interval.
Related
Premise: I have a calendar-like system that allows the creation/deletion of 'events' at a scheduled time in the future. The end goal is to perform an action (send message/reminder) prior to & at the start of the event. I've done a bit of searching & have narrowed down to what seems to be my two most viable choices
Unix Cron Jobs
Bree
I'm not quite sure which will best suit my end goal though, and additionally, it feels like there must be some additional established ways to do things like this that I just don't have proper knowledge of, or that I'm entirely skipping over.
My questions:
If, theoretically, the system were to be handling an arbitrarily large amount of 'events', all for arbitrary times in the future, which of these options is more practical system-resource-wise? Is my concern in this regard even valid?
Is there any foreseeable problem with filling up a crontab with a large volume of jobs - or, in bree's case, scheduling a large amount of jobs?
Is there a better idea I've just completely missed so far?
This mainly stems from bree's use of node 'worker threads'. I'm very unfamiliar with this concept
and concerned that since a 'worker thread' is spawned per every job, I could very quickly tie up all of my available threads and grind... something, to a halt. This, however, sounds somewhat silly & possibly wrong(possibly indicative of my complete lack of knowledge here), & thus, my question.
Thanks, Stark.
For a calendar-like system, it seems you could query your database to find all events occuring in the next hour, then create a setTimeout() for each one of those. Then, an hour later, do the same thing again. Then, upon any server restart, do the same thing again. You don't really need to worry about events that aren't imminent. They can just sit in the database until shortly before their time. You will just need an efficient way to query the database to find events that are imminent and user a timer for them.
WorkerThreads are fairly heavy weight items in nodejs as they create a whole separate heap and a whole new instance of a V8 interpreter. You would definitely not want a separate WorkerThread for each event.
I should add that timers in nodejs are very lightweight items and it is not problem to have lots of them. They are just stored in a sorted linked list and only the insertion of a new timer takes a little bit more time (to do an insertion sort as it is added to the list) as the list gets longer. There is no continuous run-time overhead because there are lots of timers. The event loop, then just checks the first item in the linked list to see if it's time yet for the next timer to fire. If so, it removes it from the head of the list and calls its callback. If not, it goes about the rest of the event loop work items and will check the first item in the list again the next through the event loop.
I'm not quite sure how timekeeping works in linux short of configuring an NTP server and such.
I am wondering if there is a way for me to make time tick faster in linux. I would like for example for 1 second to tick 10000 times faster than normal.
For clarification I don't want to make time jump like resetting a clock, I would like to increase the tick rate whatever it may be.
This is often needed functionality for simulations and replaying incoming data or events as fast as possible.
The way people solve this issue is that they have an event loop, e.g. libevent or boost::asio. The current time is obtained from the event loop (e.g. the time when epoll has returned) and stored in the event loop variable current time. Instead of using gettimeofday or clock_gettime the time is read from that current time variable. All timers are driven by the event loop current time.
When simulating/replaying, the event loop current time gets assigned the timestamp of the next event, hence eliminating time durations between the events and replaying the events as fast as possible. And your timers still work and fire in between the events as they would in the real-time but without the delays. For this to work your saved event stream that your replay must contain a timestamp of each event, of course.
I made a multiThread download application, and now I got to show the progress of each downloading Thread, like in IDM, When Data is downloaded the progressbar is notified about downloaded data, and as you know each thread position in progressBar had to begin from a specified position, now the question is:
How can I increment progressposition according to downloaded data, it is pretty simple in monothread by using IDHTTPWORK, so can I use the same method in multithread application or is there another simple method to implement?
Do I need to synchronise the instructions that increment position?
Suppose you have N downloads, of known size M[i] bytes. Before you start downloading, sum these values to get the total number of bytes to be downloaded, M.
While the threads are working they keep track of how many bytes have been downloaded so far, m[i] say. Then, at any point in time the proportion of the task that is complete is:
Sum(m[i]) / M
You can update the progress out of the main thread using a timer. Each time the timer fires, calculate the sum of the m[i] counts. There's no need for synchronisation here so long as the m[i] values are aligned. Any data races are benign.
Now, m[i] might not be stored in an array. You might have an array of download thread objects. And each of those objects stored all the information relating to that download object, including m[i].
Alternatively you can use the same sort of synchronized updating as you do for single threaded code. Remove the timer and update from the made thread when you get new progress information. However, with a lot of threads there is a lot of synchronization and that can potentially lead to contention. The lock free approach above would be my preference. Even though it involves polling on the timer.
You can take a look at the subclassed MFC list controls developed in the article by Michael Dunn 15 years ago: Articles/79/Neat-Stuff-to-Do-in-List-Controls-Using-Custom-Dra on codeproject dot com.
If you implement one of them, say, CXListCtrl* pListCtrl, at thread creation time, then the progress reporting of that thread becomes as simple as making calls such as:
pListCtrl->SetProgress(mItem,0);
when it's time to start showing progress, and
pListCtrl->SetProgress(mItem,0, i);
when you're i% done.
Actually, if you just want the progress bar functionality and don't care about all that's under the hood, you could obtain and use without modification (or license issues) the class XListCtrl.cpp in the Work Queue article at Articles/3607/Work-Queue on that same site.
Im new to threads, therefore im not sure if threads are the right way to approach this.
My program needs to perform a calculation a couple of times, same logik behind it, but with different parameters. The longer the calculation, the closer it will be to the perfect answer. The calculation duration cant be measured beforehanded (from a few seconds to a couple of minutes)
The user wants to have the results in an order (from calculation 1 to X) at certain times. He is satisfied with not the perfect solution as long as it he gets a result. Once he has a solution, he is not interested in the one before (example: he has a not perfect answer from calculation 1 and demands now answer from calculation 2; even if there is a better answer now for calculation 1, he is not interested in it)
Is threading the right way to do this?
Threading sounds like a good approach for this, as you can perform your long-running computation on a background thread while keeping your UI responsive.
In order to satisfy your requirement of having results in an order, you may need a way of stopping threads that are no longer needed. Either abort them (may be extreme), or just signal them to stop and/or return the current result.
Note you may want the threads to periodically check back in with the UI to report progress (% complete), check for any abort requests, etc. Although this depends entirely upon your application and is not necessarily required.
I'm a real beginner in multithreading. This question is about high-level multithreading in PyQt.
Suppose that a table widget requires much time to be populated because of some single items, making the window unresponsive meanwhile.
So I imagine that a responsive window should require a multithreaded solution in this case, where the big calculations (not every ones) are supposed to use separate threads.
A simpler version could use a separate thread for every single column instead of single items.
Working examples are really appreciated.
Thank you and sorry for my bad english.
EDIT: I removed the 'QtConcurrent' "requisite" from my original question.
I don't have a working example on hand for you at the moment, but I can at least offer a suggestion...
You can create a QThread (or a pool) that loops on a Queue.
Your main gui thread can place a data structure into the queue that includes the input parameters, and the destination cell (row/col).
The thread loop receives a new item from the queue, does the calculation, and then emits a signal like cellDataReady(row, col, value).
This way you can run through the table data and at any time when a calculation is needed, just queue it up.
If you want to do it the QThreadPool route, all of the threads can be pulling from the same queue object. Whichever one is free next will grab the next item, calculate, and emit.
Emitting signals from the threads will allow your main gui to connect to them and simply add the value into the table.