Thank you for your responses. The scenario (I forgot in my first post): I'm trying to improve I/O accesses (disk/network...).
So, if a Python thread map with a OS 1:1 thread, and the main problem (I understood that) is the cost of context switching between of threads/coroutines... this raises me a new question: If I only run a process with 1 thread (the default state) the GIL will change the context after the thread ticks was spent? Or the behavior is like a plain run until the program ends? Thinking about that, I suppose that if the status is 1 process <-> 1 thread, without context change, obviously the best approach for high performance network I/O are with creating coroutines and not threads, right? I'm wrong? En 19 de abril de 2016 en 0:54:28, Guido van Rossum (gu...@python.org) escrito: On Mon, Apr 18, 2016 at 1:26 PM, Imran Geriskovan <imran.gerisko...@gmail.com> wrote: A) Python threads are not real threads. It multiplexes "Python Threads" on a single OS thread. (Guido, can you correct me if I'm wrong, and can you provide some info on multiplexing/context switching of "Python Threads"?) Sorry, you are wrong. Python threads map 1:1 to OS threads. They are as real as threads come (the GIL notwithstanding). -- --Guido van Rossum (python.org/~guido) --- Daniel García (cr0hn) Security researcher and ethical hacker Personal site: http://cr0hn.com Linkedin: https://www.linkedin.com/in/garciagarciadaniel Company: http://abirtone.com Twitter: @ggdaniel
signature.asc
Description: Message signed with OpenPGP using AMPGpg
