[issue12850] [PATCH] stm.atomic

Armin Rigo 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. This goes against the idea, whi

[issue12850] [PATCH] stm.atomic

Changes by Georg Brandl : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue12850] [PATCH] stm.atomic

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12850] [PATCH] stm.atomic

Armin Rigo added the comment: :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue12850] [PATCH] stm.atomic

Terry J. Reedy 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 relieve us of any oblig

[issue12850] [PATCH] stm.atomic

Armin Rigo 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 suggestion. I am also fine if this

[issue12850] [PATCH] stm.atomic

Nick Coghlan 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. Offering this API

[issue12850] [PATCH] stm.atomic

Armin Rigo 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 would look like that: /* st

[issue12850] [PATCH] stm.atomic

Antoine Pitrou 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 implementation

[issue12850] [PATCH] stm.atomic

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue12850] [PATCH] stm.atomic

Armin Rigo 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 _at the next cross-bytecode

[issue12850] [PATCH] stm.atomic

Nick Coghlan 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 :) --

[issue12850] [PATCH] stm.atomic

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12850] [PATCH] stm.atomic

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue12850] [PATCH] stm.atomic

Armin Rigo 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 "internal use only" anyway, so de

[issue12850] [PATCH] stm.atomic

Nick Coghlan 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 */ _PyEval_GIL_func _PyEval_re

[issue12850] [PATCH] stm.atomic

Armin Rigo 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 __

[issue12850] [PATCH] stm.atomic

Changes by Nadeem Vawda : -- nosy: +nadeem.vawda ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue12850] [PATCH] stm.atomic

New submission from Armin Rigo : 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 With this patch, it is possib