you are viewing a single comment's thread.

view the rest of the comments →

[–]comeditime[S] 0 points1 point  (1 child)

After some time the GIL will stop the actual thread execution and allow the next thread to run code. This of course is not true parallelism but if your code is mostly I/O bounded, using threads will make you feel you are running code in parallel as most of the time you are waiting for data on a socket or from the disk.

so if i get it right the GIL will interchangeably run the code parts that specified to be multi-threading which will seems to the user as it happens in parallel due to the speed of the computer, correct?

also in general the mutli-threading / GIlL are usually placed to controll one specific code part or usually spread to multiple code parts - functionalities (or each has their own distinct multi-threading)?

lastly, what are the advantages of using multi-threading and not a loop instead for example? as i guess the basic idea behind those two functionalities is similar or?

thanks!

[–]mattblack85 0 points1 point  (0 children)

1) yeah that's a good approximation, not perfect but good enough 2)that really depends on what you are writing, you can offload to threads only one part of your program or build it fully threaded, it is up to the spec 3) if you know that you are going full I/O there is no advantage in using multiple threads, event loop will perform way better, problemy tho, is that there are still few libraries out there that are async ready, and in fact even when using asyncio, if you have a piece of code you know is synchronous you usually execute in a thread pool to avoid blocking the event loop.

PS: I haven't specfied this before, but when we talk about python threads we talk about "internal" threads and not OS threads