Am I understanding correctly that wait-free writes are not supported?

[stevenroose]

I was about to start using this package because I have a single-writer, multi-reader setup where the write operation cannot wait for readers, so a traditional RwLock or Mutex can be annoying. The description says that evmap has "lock-free writes" but I don't see how that would work. Both flush and refresh will block the writer until the readers are done.

I would want a situation where writers can freely add operations without every having to wait and as soon as there are no more readers, the readers' side is updated. But on the readers' time, not on the writer's time.

It seems like with "lock-free writes" you are intending to say "writes don't prevent new reads", it seems ambiguous as I took it to mean "writes don't need to wait for a lock".

[stevenroose]

Maybe there could be something like a try_refresh or try_flush method, but that would not be ideal as it would mean that if it fails, the refresh can only happen next time try_refresh would be called.

A set_ready_to_refresh would be better. But I was under the impression that was what flush would do. But it seems not to be the case.

[jonhoo]

You're technically correct, which is the best kind of correct! One could argue that writes to the map are wait free, because, well, the pure write operation is, but once you take into account having to also expose them to readers, then they're not wait free any more. I think updating the description is a good idea, if you want to submit a PR?

Adding a try_refresh and try_flush makes a lot of sense to me! Happy to take a look at a PR if you have a chance.

As for the larger feature of essentially "scheduling" a refresh to happen whenever it becomes possible, this one is actually quite tricky. The big question is what to do with modifications to the map between when refresh returns and when the readers have actually moved on and one of the maps is available for writes. You could stick them in the oplog, but handling the logic of that oplog then becomes significantly more complicated. Especially once you take into account that another refresh could happen while readers are still now in both maps!