Home » Community » Coffee corner » MT opens up whole new can of worms :)
MT opens up whole new can of worms :) [message #46136] |
Wed, 16 March 2016 14:03 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
So I started doing heavy MT for all my IDE related tasks, and man, nothing works as it did anymore. All the GUI conventions are thrown on their back, like when you edit some code, which launches a thread, which eventually finishes while you edit, which differentially updates the code navigator, re-parses documentation comments, all while triggering events left and right, having unexpected cursor change and content edits events.
Do you guys do MT GUI?
|
|
|
Re: MT opens up whole new can of worms :) [message #46139 is a reply to message #46136] |
Wed, 16 March 2016 17:16 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
cbpporter wrote on Wed, 16 March 2016 14:03So I started doing heavy MT for all my IDE related tasks, and man, nothing works as it did anymore. All the GUI conventions are thrown on their back, like when you edit some code, which launches a thread, which eventually finishes while you edit, which differentially updates the code navigator, re-parses documentation comments, all while triggering events left and right, having unexpected cursor change and content edits events.
Do you guys do MT GUI?
I guess there is a good reason why majority of frameworks has "GUI thread" concept
Mirek
|
|
|
|
Re: MT opens up whole new can of worms :) [message #46160 is a reply to message #46144] |
Mon, 21 March 2016 10:41 |
cbpporter
Messages: 1406 Registered: September 2007
|
Ultimate Contributor |
|
|
Well, I do all the GUI stuff on the main thread.
Still, after years of experience with GUI, you get a very good feel of when and why events should trigger and you learn to write short code that best uses these rules.
With MT, events trigger all around in non deterministic orders and the only good solution I found is to turn some off while background threads are running and turn them back on once they are done, combined with a ticketing system, so that the event can't be triggered only if the tickets match.
One rather simple example is editing code vs. updating a code navigator. If you do it with ST, once the code analysis is done, the navigator can be updated, which will sometimes resolve in an order change of items and the cursor position must be changed. So an event will be triggered and the cursor in the editor changed, but this is not a problem since the cursor is restored after the navigation update procedure. With MT, if the cursor changes due to a thread, events shouldn't trigger since that makes the editor incapable of doing mouse select, but if you click on it, it should work.
The rest of the cases are more complicated than this.
|
|
|
Goto Forum:
Current Time: Sat Sep 21 06:45:26 CEST 2024
Total time taken to generate the page: 0.03436 seconds
|