[Tutor] What exactly does await do? (ThreeBlindQuarks)(David)

[Alan Gauld]

On 19/02/2023 11:20, Alphonsus wrote:

> question, I am actually writing a gui program but it is expected to do
> a ton of request and on request by the user read a file, but while the
> file is being read, I do not expect the program gui loop to stop, and
> this is the same with the request.

This is a classic scenario for threading. You could do it with async
but that means running an async loop inside the gui loop which gets
messy. The easiest way is to launch an async thread to run its loop.
But if you are launching a thread then why not just read the file
in the thread instead?

There are some well publicised(over publicised?) issues with Python
threading but those don't apply to I/O intesive operations like
reading files.

> Normally I read a file using something like this:
> with open(filename, 'r') as file_object:
>     file_object.read()

And thats fine inside a thread too.
Just make sure you sabe the data into a variable accessible once
the thread completes and set some kind of semaphore/flag to
indicate when the data is safe to use. (ie you've finished
the thread)

> but it is my experience that this will stop the gui loop temporarily
> and this becomes noticeable if the file is large. Looking at the
> python docs, there are three candidates to solve this problem,
> asyncio, threading or multiprocessing

Generalizing very broadly
- Asyncio is best for building transaction processors. I don't
tend to use it with GUI driven programs. Its better in a
server role IMHO.

- Multiprocessing is good where the task is long running and
indeterminate in nature (reading a file is relatively short
and has a determinate end - when the file is read) For
example if you had a "server" process that yout GUI used
to perform calculations on an ad-hoc basis during the life
of the program. Then starting a concurrent process to do
the background processing makes sense. Also, due to
Python's threading design processor intensive work would
make sense. Say you had an IDE program and wanted to
run compilations of your code in the background I'd probably
choose to use a concurrent process rather than a thread.
Or in a Video editor rendering the video could be another case.

- Threads are good for quick(relatively) tasks that would
block the GUI but will definitely terminate in "user
time". Examples being to read a data file, do a spell
check etc.

Of course, it's not black and white and many will probably
disagree with my arbitrary choices above. You can do parallel
processing in many ways and there are no absolute rules.

> I should also add that I found aiofiles package for reading to files

A new one on me!

> There are still things I do not understand but in trying to keep
> things simple, I will ask only one question at a time and only if I
> have understood and still find it necessary do I proceed with another
> question?

That's a good approach because asking multiple questions
leads to confusing responses where it's not clear which
question is being answered!

> mind), I am looking for information of the objects that will appear in
> the code, what the object will be doing, the functions that will be
> needed in the code, what the functions will be doing, the loop and
> what will be happening each time through the loop. Just general
> information from which I can research further on. I just wish to
> understand the concepts, not burden anyone with my tasks.

In my tutorial(see below) I have three topics (in the advanced
section) devoted to parallel processing using fork(), threading
and multiprocessing. The examples may be too simple for your
purposes but you might find the discussion useful.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/l2p2
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos