[ python-Feature Requests-1432694 ] Implement preemptive threads in Python

[SourceForge.net]

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