Feature Requests item #1432694, was opened at 2006-02-16 10:11 Message generated for change (Comment added) made by darkprokoba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None >Status: Pending Resolution: Invalid Priority: 5 Submitted By: Andrey Petrov (darkprokoba) Assigned to: Michael Hudson (mwh) Summary: Implement preemptive threads in Python Initial Comment: Cooperative threads have their uses but I find the lack of real native pre-emptive threads a major issue in a 21-st century language. We should consider the inertia of programmers from C++/Java/.NET background. They are used to and experienced in solving certain kind of problems with pre-emptive threads, and it's just too plain inconvenient to step back and try to cope with cooperative threads. The idea behind Python is that programming should not be a pain, right? This applies especially to GUI programs, where threads are used to perform time-consuming work in order to avoid the GUI from freezing (was I surprised the first time I tried this in Python!) Just look at some of the modern Python GUI applications, found in some recent Linux distributions. 99% of Fedora's configuration tools suffer extreme usability issues caused by their single-threadedness. I hate using yumex because the GUI is basically frozen for the half minute it takes to reload all repos I have configured on my machine!!! I know there might be a way to alleviate this particual class of problems by more careful cooperative thread programing... but I believe we need a more straightforward solution (i.e. preemptive threads) and not workarounds. I apologize if this issue has already been raised before. Cheers, darkprokoba ---------------------------------------------------------------------- >Comment By: Andrey Petrov (darkprokoba) Date: 2006-02-17 11:52 Message: Logged In: YES user_id=950037 OK, let me try again :-) The problem is in the global interpreter lock: http://docs.python.org/api/threads.html this basically says that you can have as many native threads as you like but only one of them could have the global interpreter lock and could therefore be executing python code at a time. The only use of python's multiple threads then is so they could release the global lock and block on i/o operations while one lucky thread has the lock and executes python code and accesses python objects happily. So we have multiple native threads (e.g. pthreads) but they pass arround the global lock in a cooperative manner. This is not preemptive threading imho. It's a severely limited model and has the following potential problem: a thread may enter a time-consuming i/o operation but forget to release the global interpreter lock - leading to a freeze in the entire interpreter (all threads are waiting for the global lock, while the thread that has it waits on the i/o operation) Are there any plans for alleviating this problem? A thread should not voluntarily release the lock so that the rest of the threads get a chance to execute python code. It should be possible to preempt any thread at any time without its consent in order to have a true preemptive threading model. Or please correct me If I'm wrong. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-16 16:14 Message: Logged In: YES user_id=6656 We _have_ preemptive threads in Python ("import threading"). Suggest you report a real problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
