Bruno Desthuilliers wrote: > rushen...@gmail.com a écrit : > (snip) >> And the story begins here. As i search on the net, I have found that >> because of the natural characteristics of python such as GIL, we are >> not able to write multi threaded programs. > > I'm surprised no one here corrected that point yet, so here we go: yes, > Python does support multithreading. The fact that threads won't be > executed concurrently on a multicore machine (due to the GIL) is a > different problem (cf Andrew Cooke's answer on this - and his advice to > study Erlang if you want to do concurrent programming).
ah, sorry, i noticed this last night in another comment from rushenaly, but forgot to say anything. in case it's still not clear: you can have threads even on a single core. this is done by "time slicing" - some cpu time is given to one thread, then to another. exactly who does the slicing can vary. in the case of a gui (which is what i was about to explain last night then got distracted) it's quite common for the gui library itself to do the scheduling of work. so even though the gui library uses a single thread, it can update several windows, handle user input, etc "in parallel". the next level is that the language itself does the scheduling - that's what is commonly called "threads". finally the operating system can share things out (and that's called processes). but these are all basically the same thing, can happen on a single core, and are not affected by the GIL (i have simplified above; threads can also be a service that the operating system provides to a language) andrew -- http://mail.python.org/mailman/listinfo/python-list
