Hi all,
once I wrote a piece of code implementing "software transactional memory". The sugar part of it is in the tests[1]: handler can be attached to the transaction. The latter feature was used to implement a small data flow language embedded in Scheme. I miss it under gambit.
If there was a STM implementation for gambit, which I could start from, please tell me. It could be quite a short cut.
Otherwise I need help to understand three things:
1. Atomicity in GVM
To start with I could always just have a global lock instead of lock-free updates. Optimizations might be done later. (Likely crazy, but let's see.)
But I wonder: how are signal handlers actually handled? Can I declare a `for-each` statement in such a way that the GVM sees no signal handler running during execution time? Also, there appears to come some multi threaded GVM our way: will this be the case in the future too?
Background: the heart of the implementation is a list of in-transaction-value records, which need to be written back to the global scope atomically.
2. Defining yet another record type. Much like SRFI-9 just two actual slots per record field, the value and a version tag. Likely doable, but the tricky part: how do I hide the version tag accessors from user code?
3. For *each slot* of a record X of type Y defined using the definition from step 2, I need to be able to create another record ITV[2]. The `for-each` from #1 traverses a ist of ITV checks the version tag from ITV against X's tag and if all goes well, copies the value field from ITV to X.
In the original code, ITV holds a pointer to X and an integer offset into X representation. (A low level chicken feature `##sys#slot`.) Is there something alike in gambit?
Thank you so much
Jörg
[1] https://github.com/0-8-15/hopefully/blob/03210411161e0df057cabf9fae734688200... [2] ITV: in-transaction-value