[Python-ideas] Thread stopping
fuzzyman at gmail.com
Mon Apr 2 13:56:05 CEST 2012
On 1 April 2012 04:50, Gregory P. Smith <greg at krypto.org> wrote:
> On Sat, Mar 31, 2012 at 3:33 AM, Michael Foord <fuzzyman at gmail.com> wrote:
>> An "uninterruptable context manager" would be nice - but would probably
>> need extra vm support and isn't essential.
> I'm not so sure that would need much vm support for an uninterruptable
> context manager, at least in CPython 3.2 and 3.3:
> Isn't something like this about it; assuming you were only talking about
> uninteruptable within the context of native Python code rather than
> whatever other extension modules or interpreter embedding code may be
> running on their own in C/C++/Java/C# thread land:
> class UninterruptableContext:
> def __enter__(self, ...):
> self._orig_switchinterval = sys.getswitchinterval()
> sys.setswitchinterval(1000000000) # 31 years with no Python thread
> def __exit__(self, ...):
> the danger with that of course is that you could be saving an obsolete
> switch interval value. but I suspect it is rare to change that other than
> near process start time. you could document the caveat and suggest that the
> switch interval be set to its desired setting before using any of these
> context managers. or monkeypatch setswitchinterval out with a dummy when
> this library is imported so that it becomes the sole user and owner of that
> api. all of which are pretty evil-hacks to expunge from ones memory and
> pretend you didn't read.
> the _other_ big caveat to the above is that if you do any blocking
> operations that release the GIL within such a context manager I think you
> just voluntarily give up your right to not be interrupted. Plus it depends
> on setswitchinterval() which is an API that we could easily discard in the
> future with different threading and GIL implementations.
> brainstorming... its what python-ideas is for.
> I have zero use cases for the uninterruptable context manager within
> Python. for tiny sections of C code, sure. Within a high level language...
> not so much. Please use finer grained locks. An uninterruptible context
> manager is essentially a context manager around the GIL.
I think you misunderstand what we mean by uninterruptable. It has nothing
to do with *thread switching*, the interruption we are talking about is the
proposed new feature where threads can be terminated by raising a
ThreadInterrupt exception inside them. An uninterruptable context manager
(which I'm not convinced is needed or easy to implement) simply means that
a ThreadInterrupt won't be raised whilst code inside the context manager is
executing. It *does not* mean that execution can't switch to another thread
via the normal means.
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas