It has taken me a long time to get back to this, the algorithm I am
playing with is soft real-time at best not hard realtime
My thinking is far more around using (and abusing) the transaction queue
to manage a barrier for the GC implementing much of a classical
read/write barrier there
On 25/02/12 09:42, Armin Rigo wrote:
Re-hi,
Ah, another matter. I don't know how interesting the goal of a
no-pause GC is together with STM. It would seem to me that STM is, by
itself, not really well-suited if you want to absolutely avoid pauses:
if a transaction is aborted a few times before eventually succeeding
to commit, then you have an unexpected pause between the time were the
transaction was first started and the time were it committed. I think
it's a built-in property of all transactional memory systems to not be
really "real-time safe". Maybe they can be made real-time safe by
falling back to nontransactional single-threaded execution at some
point, but that looks more advanced that I care for right now.
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
