Armin Rigo ar...@users.sourceforge.net added the comment:
Closing the request for this patch. It is unsatisfactory that it only offers
the basic user-level STM feature of transaction, but not, say,
abort_and_retry() or any other feature generally found in real-world STM
implementations.
Changes by Georg Brandl ge...@python.org:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Python-bugs-list
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Python-bugs-list mailing list
Armin Rigo ar...@users.sourceforge.net added the comment:
:-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
I quite like the last idea. Something like:
_PyEval_SuspendOtherThreads(PyThreadState *tstate, PyThread_lock_type lock);
All threads other than tstate will be prevented from executing further
interpreter bytecodes until lock is released.
Armin Rigo ar...@users.sourceforge.net added the comment:
That's why I don't really know which concept is the best: the core of
transactionmodule.c is just about one page in length, so there are only so many
ways to split this code between CPython and the module...
Attached the latest
Terry J. Reedy tjre...@udel.edu added the comment:
Semi-seriously, _PyEval_ForArminRigoOnly_
/* This function does whatever Armin Rigo wants it to do.
He may change it at any time. Do not use it. */
This would let you experiment with the boundary as you will (with review, of
course) and
Antoine Pitrou pit...@free.fr added the comment:
I'm worried that by allowing users to pass function pointers here, we are
allowing all kinds of uses that we will have to more or less support later.
What exactly taking the GIL means and when exactly it is done in the
execution process is an
Armin Rigo ar...@users.sourceforge.net added the comment:
Antoine: we could take two lines from the current implementation of these hook
from stm/transactionmodule.c, and move them to the interpreter core. CPython
would end up with containing the core logic for transactions. A possible API
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Nothing specific, just a reflexive C++ induced dislike for linker-accessible
globals in general.
However, while I slightly prefer the function driven API, I wouldn't actively
oppose direct linker access if someone else wanted to check it in
Armin Rigo ar...@users.sourceforge.net added the comment:
Ok, I followed Nick's suggestion, and I finally found out how to write the code
in order to avoid all (or most?) deadlocks without any change in the rest of
CPython. It requires a way to be sure that some callback function is invoked
New submission from Armin Rigo ar...@users.sourceforge.net:
Here is (attached) a minimal patch to the core trunk CPython to allow extension
modules to take over control of acquiring and releasing the GIL, as proposed
here:
http://mail.python.org/pipermail/python-dev/2011-August/113248.html
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Armin Rigo ar...@users.sourceforge.net added the comment:
NB. I know that my stmmodule.c contains a gcc-ism: it uses a __thread global
variable. I plan to fix this in future versions :-)
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
Rather than exposing the function pointers directly to the linker, I'd be
happier with a function based API, with the pointer storage then being made
static inside ceval.c.
/* Each function returns the old func, or NULL on failure */
Armin Rigo ar...@users.sourceforge.net added the comment:
I suppose I'm fine either way, but do you have a reason for not exposing the
variables to the linker? Some Windows-ism were such exposed variables are
slower to access than static ones, maybe? The point is that they are kind of
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12850
___
___
Python-bugs-list mailing
19 matches
Mail list logo
