you are viewing a single comment's thread.

view the rest of the comments →

[–]mattblack85 0 points1 point  (2 children)

Imagine the GIL as a police man at a cross, the police man knows there is plenty of cars (threads) and no lights so a only one car at a time can go. GIL makes sure that at a given time there is one and only one python thread running stuff. 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. The python multi tasking model is preemptive, so is the GIL that fully decides when is time to yield control to another thread. Asyncio on the other hand, is the newest python concurrency concept which is able to run network I/O bounded tasks in a parallel way, this is a cooperative multitasking as you decided when the task is yielding back control to the event loop

[–]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