OpenEuphoria

Re: doEvents() [Part 2] AKA the Threads discussion

• Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 28, 2005
• 421 views

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
>
>
>
>
>