improve UI responsivenes / use worker threads

[Onkar Shinde]

Apparently, the UI code is currently being run in the same thread as the rest of the simulator, this is problematic as it may result in a lack of responsiveness of the GUI, it would be good if either the UI code could be put into a corresponding worker thread, or alternatively the simulator core itself

[Bug Importer (bug-importer)]

Logged In: NO

a locked up GUI is only likely to become a problem once you have an infinite loop, i.e. because you forget to put a HLT statement into your code, otherwise all code is likely to be executed immediatley until it finishes, so that the GUI will be responsive again directly after having finished the simulation of the program.
So, threading, be it the GUI or the simulation engine, would only really help to debug a non-trivial program while it is *running*, assuming it would have to run longer than just a couple of msecs or seconds.
Note that even running the program in debugger/step by step mode, will NOT lock up the simulator because the engine will return control to the UI, once a statement has been executed.

[Bug Importer (bug-importer)]

Logged In: NO

the docs at http://gnusim8085.sourceforge.net/doc/asm-guide.html at explicitly state "* Don't forget to include the HLT instruction somewhere else in the program to terminate it, otherwise you will be fooled!"

Assuming that threads would be non trivial for starters, it might be sufficient to provide an option (checkbox) to automatically check each program for the corresponding HLT instruction/opcode before running it, so that this may optionally result in a corresponding warning that the program is apparently lacking a HLT instruction.

Of course this can easily become non-trivial for multiple execution branches.

Thus, maybe using a meta directive such as ".end" might be another option

[Bug Importer (bug-importer)]

you could also specify a timeout value, once this is reached the user may optionally be asked to interrupt execution to make the UI responsive again

[Bug Importer (bug-importer)]

I just managed to accidentally run into an infinite loop, the simulator was unusable then-this is really unfortunate, because it may even mean a loss of code, if you forgot to save your changes. Maybe there needs to be some small button or other UI item that allows the user to interrupt the simulator on demand?
Or at least a custom, configurable timeout interval-in milliseconds, so once the simulator spends more than this configurable amount of time running, the user could optionally stop it.

This works basically the same as in firefox, where a simple javascript may block the whole browser, after a certain amount of time firefox asks you if you want to keep running the code or cancel it.

This seems elegant enough for our situation, too. In particular because the user could easily customize this value on demand, so if a certain program does indeed take a couple of seconds (or longer) to fully complete, the user could configure a custom timeout value that is long enough.

Apart from that, separating the UI code from the simulator code would still be the right thing to do, in order to ensure that the UI remains responsive!

[Bug Importer (bug-importer)]

you could also have a configurable warning in the UI that optionally allows the user to be warned if they run a snippet of code that lacks a hlt instruction, likewise we could try to recognize typical infinite loops and warn the user if there seems to be one.

[Bug Importer (bug-importer)]

one could also use the concept of a coroutine to optionally interrupt simulation at some point in order to temporarily return control to the UI, so that the UI remains responsive and can be used to cancel the simulation.

[Bug Importer (bug-importer)]

if coroutines were to be used, wouldn't that make the timing and behavior of the program completely unreliable?