1. doEvents() [Part 2] AKA the Threads discussion
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Apr 25, 2005
-
Last edited Apr 26, 2005
Never knowingly used threads myself, and am getting some results with
a single idle routine, but I sense a struggle ahead; to be honest I
sense that struggle would be worse with threads, but I will of course
stand being corrected. Let me explain.
At the moment Edita has a small handful of things to do:
load the files (not currently b/g)
paint the screen
scan for routine/variable/block (incomplete)
monitor a previously executed program.
It also attempts to do some of these things straightaway, as user
input/whatever be the current file, makes them a priority. I have hit
the first (of many?) problems whereby a scan running in the background
because the program senses it is idle interferes with a scan running
due to user input. That one case is solved with a simple flag.
What is the general strategy for lots of things running at the same
time so they don't dump on one another?
As a specific example, I open an editor with 4 files from the
edita.ini file, so I start a deep analysis of file 4 in the
background; and the user switches to file 3 before I am done.
Do I cancel file 4 completely? suspend it somehow? Make sure all local
vars really are local (and not file-level)?
Another: Suppose I am scanning a file for procedure/type definition
line numbers, and while I'm half way through, the user hits CR,
inserting a line break and upsetting all later line numbers?
Do I update (my local copy) so far and any new, do I abort and start
again?
Well complex...
Suggestions and thoughts, anyone?
Would threads genuinely help in a dynamic situation?
Regards,
Pete
2. Re: doEvents() [Part 2] AKA the Threads discussion
On 4/25/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
>
> Never knowingly used threads myself, and am getting some results with
> a single idle routine, but I sense a struggle ahead; to be honest I
> sense that struggle would be worse with threads, but I will of course
> stand being corrected. Let me explain.
>
> At the moment Edita has a small handful of things to do:
>
> load the files (not currently b/g)
> paint the screen
> scan for routine/variable/block (incomplete)
> monitor a previously executed program.
>
> It also attempts to do some of these things straightaway, as user
> input/whatever be the current file, makes them a priority. I have hit
> the first (of many?) problems whereby a scan running in the background
> because the program senses it is idle interferes with a scan running
> due to user input. That one case is solved with a simple flag.
>
> What is the general strategy for lots of things running at the same
> time so they don't dump on one another?
>
> As a specific example, I open an editor with 4 files from the
> edita.ini file, so I start a deep analysis of file 4 in the
> background; and the user switches to file 3 before I am done.
> Do I cancel file 4 completely? suspend it somehow? Make sure all local
> vars really are local (and not file-level)?
>
> Another: Suppose I am scanning a file for procedure/type definition
> line numbers, and while I'm half way through, the user hits CR,
> inserting a line break and upsetting all later line numbers?
> Do I update (my local copy) so far and any new, do I abort and start
> again?
>
> Well complex...
>
> Suggestions and thoughts, anyone?
> Would threads genuinely help in a dynamic situation?
The answer to both is YES. Threads would help a ton, you could have
the user open up a hundred files at the same time, and make a thread
for each, and switch between files at random, and close them(thereby
killing the thread processing it too). And one thread for the GUI,
which would probably be the original thread.
Dan
>
> Regards,
> Pete
>
>
>
>
>
