libera/#sicl - IRC Chatlog
Search
11:28:38
hayley
So, the main arguments are that it is difficult to implement atomic updates with mmap, and that TLB shootdowns can be slower than syscalls?
11:31:31
hayley
There is a similar problem to the latter when implementing concurrent garbage collectors using hardware protection, wherein many mprotect calls are made in a batch, but the operating system flushes(?) TLBs after every call. And I think there is also a tradeoff with calling mmap in a grep implementation too.
11:32:11
hayley
Conventional wisdom for the latter is to read whole files into memory if they are small, and mmap if they are large.
11:32:46
hayley
Isn't madvise with the sequential option supposed to do (linear) prefetching? But sure about any other patterns.
11:33:28
moon-child
but when you know what you're going to look at, you can do better. They give an example in the paper. See also ocaml list iteration, mentioned recently :)
11:36:26
moon-child
but atomicity&transactions are the main thing I worry about. Was thinking about them a bit ago too. I have no idea how you make that work well in a large system. Databases tend to be self-contained, but you ideally also want to maintain coherent inter-process state too
11:38:32
hayley
I've discussed it with someone before, and we thought to allow programs to force the supervisor to generate a checkpoint, which would ensure durability (insofar as the hardware is durable too). The other three parts of ACID are harder, but we can just use software transactional memory.
11:40:38
hayley
If you checkpoint threads too, and the supervisor automatically generates a checkpoint while a transaction is being produced, then I would expect that threads will roll forward as usual after a crash, unless some non-determinism influences execution.