[Python-ideas] Thread stopping

[Michael Foord]

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
> switching
>
>   def __exit__(self, ...):
>     sys.setswitchinterval(self._orig_switchinterval)
>
> 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.
>
>
Hello Gregory,

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.

Michael



> -gps
>



-- 

http://www.voidspace.org.uk/

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...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120402/a3e654cc/attachment.html>