Concurrency in Reaction
Sergey Schetinin
need work before we can get real concurrency, and I have to admit it's
a bit too much for me right now -- it's not a smart way to spend my
time at this moment. While some of my projects could greatly benefit
from it, the GIL is still there, so the increased granularity we got
with new effects should be enough (the global lock is released between
transactions). So I think I will simplify a few things in the library
and leave the concurrency for some other time.
Here are a few things that make concurrency hard:
- The dependencies have to be stored transactionally -- listeners of
the same cell could be different in concurrent transactions
- Becoming a constant -- a cell becoming a constant changes its
__class__. If a different transaction reads that cell it might miss a
read invalidation or even worse -- this just doesn't play well with
concurrency.
- Layer management -- reads and writes sometimes change layers of
involved cells which also changes the queue they are in, this again
doesn't work well in concurrent environment and storing this info in
txn is out of question -- it would be both overcomplicated and slow.
I still intend to keep the storage via ctrl.state[] / txn.snapshot[]
etc. I'm considering bringing a @perform-like listener back, though it
would be quite different -- it would still run after a txn, would not
be allowed to read transient values or (probably) initialize cells.
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter