Home » Community » U++ community news and announcements » AsyncWork
|
|
|
|
Re: AsyncWork [message #48864 is a reply to message #48861] |
Mon, 16 October 2017 09:04 |
|
koldo
Messages: 3372 Registered: August 2008
|
Senior Veteran |
|
|
Thank you Mirek.
(Sorry Mirek and Oblivion for an out of topic question )
In your opinion, how is the best way from the Threads to interact with GUI?:
- GuiLock
- The GUI uses SetTimeCallback() to set a timer function that updates the GUI thanks to shared variables.
Best regards
Iñaki
[Updated on: Mon, 16 October 2017 09:05] Report message to a moderator
|
|
|
Re: AsyncWork [message #48866 is a reply to message #48860] |
Mon, 16 October 2017 09:50 |
Oblivion
Messages: 1094 Registered: August 2007
|
Senior Contributor |
|
|
Quote:Dear Mirek, dear Oblivion
For a standard GUI program to have a more responsive user interface, do you propose AsynWork to launch all jobs?
(And of course, sorry for this reference, to forget forever any Ctrl::ProcessEvents() call Sad ).
Hello Koldo,
I agree with Mirek.
You should use dedicated Thread(s) (in contrast to worker threads).
While AsyncWork, hence CoWork, does a decent job here (considering that it has cancellation feature and -"experimental"- pipe support), disadvantages of thread pools in general comes into play in such scenarios.
I don't want to go into details here, so just to keep it short:
You'll usually have no control over the states and priorites of workers, or exact execution time, or sometimes, if the job will be executed in worker threads at all. Therefore building a UI on AsyncWork, or thread pools in general, is not a very good idea. UI or any other time consuming operation can easily take advantage of it, but IMO it should not be built upon it.
(See the new SSH package, for a concrete -experimental- example of AsyncWork, and how it makes things simpler (and faster, up to 2-4 times).)
P.s. But there is a middle ground if you really need something like that. An attempt build a hybrid of worker thread concept, and dedicated threads, with a reasonble control over the given thread's states and priority: Job (the one I wrote). You may also want to try that.
Best regards,
Oblivion.
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Mon, 16 October 2017 13:26] Report message to a moderator
|
|
|
Re: AsyncWork [message #48867 is a reply to message #48864] |
Mon, 16 October 2017 10:29 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
koldo wrote on Mon, 16 October 2017 09:04Thank you Mirek.
(Sorry Mirek and Oblivion for an out of topic question )
In your opinion, how is the best way from the Threads to interact with GUI?:
- GuiLock
- The GUI uses SetTimeCallback() to set a timer function that updates the GUI thanks to shared variables.
GuiLock is definitely better (it is a 'newer' thing too), except the cases where it cannot be used (that is where windows are created - this limitation is caused by win32 basic design, which creates 'per-thread'
SetTimeCallback is really just the 'oldest' mechanism. At that time, it was choosen as the 'safe' and straightforward way.
Also note that there is Ctrl::Call, which is 'synchronous' variant of SetTimeCallback. Basically performs the code in the main thread, but waits for its completion.
Now, practical experience: If all you want to do is to have application responsive while long operation is being performed, maybe with some fancy progress bar, all you need is GuiLock.
Mirek
|
|
|
|
|
|
Goto Forum:
Current Time: Wed Jun 05 09:03:24 CEST 2024
Total time taken to generate the page: 0.02005 seconds
|