libera/#sicl - IRC Chatlog
Search
19:35:59
moon-child
I am not sure about transactional memory--and I know what hayley will say about it--and I am not suggesting it. But given a policy of transparent persistence, it seems meet to accompany it with a way of controlling that persistence and ensure it remains consistent
19:37:02
moon-child
as I recall, the closos spec discusses full-system snapshotting. I don't know if that is scalable, except at distant intervals. So there must be persistence at a level less than the whole system
19:38:17
moon-child
(so when I say 'transaction', I mean an assurance about what will be written to disc; not about what in-memory state might be observed at any given point in time)
19:39:42
moon-child
one thing I considered was to separate state into 'pods' of some sort, perhaps a bit similar in spirit to erlang actors, such that one pod can never point to something in another pod. Then, transactions take place at the level of a pod. It would be possible to set up dependencies between transactions in distinct pods, such that one may not be committed before another; a bidirectional dependency
19:39:43
moon-child
constitutes a link; usually, linked transactions would only affect a small number of pods (say, a server and a client negotiating state). I don't think this is suitable for closos, as everything should be able to point to everything. But I am curious what people think about it more generally
19:42:35
moon-child
another thing I thought about was transactions at the level of a single object. This could be implemented with only two bits of overhead--really, three states: not in transaction; currently in a transaction; and transacted, but not yet committed. The object transacted over would likely be a large array, encapsulating a large number of logical objects (which might be represented as standard objects
19:42:37
moon-child
wrapping indices into this array). It would be somewhat difficult to write transaction-safe code in this way--I suspect the 'pod' approach would be much more ergonomic--but it would be possible
19:43:34
moon-child
another question is what the relationship should be between state recovery and global side effects--where by 'global' I mean 'outside of a single computer'
19:44:18
moon-child
what if, for instance, you snapshot right before launching the nukes, then launch the nukes, then crash and restore? Do you launch the nukes twice?
19:46:00
moon-child
I can imagine signalling a 'duplicated side effect' error, but I'm not sure quite how it would work. What if you ask the user whether they want to do X or Y, then snapshot, then user says 'I wanna do X', so you do X, then crash, then restore from snapshot, and this time the user says 'I wanna do Y'?
20:14:15
Bike
i'm not an expert, but if i recovered from a crash and my computer decided to redo whatever network thing for me i'd be kind of annoyed
20:14:47
Bike
like heck, when browsers crash, the page you had open reloads as a "are you sure you want to grab this page again, last time it killed me" message
22:51:58
Bike
https://github.com/s-expressionists/Cleavir/How-Cleavir-optimizes started writing up what I'm doing in Cleavir