Adopt lockless design

[mraerino]

Is your feature request related to a problem? Please describe.

The codebase is using a lot of locking right now. This can have unexpected consequences for people using the library.

Describe the solution you'd like

Adopt lockless programming using Arc and different kinds of channels instead.

There are several synchronization cases here:

• Consuming updates in the in-memory storage
  • acts like a database, so RwLock would be fair
  • Could also use arc-swap instead
• Sending batches of events
  • can be solved using channels
  • for the sync API we should consider dropping events if the channel is full, an unbounded channel can have bad consequences for the service using the SDK
• Update processing
  • Should not need a lock at all - mostly based on a serial stream of events written to the store
  • Parallel processing can be solved using channels

Describe alternatives you've considered

We could consider having different Store implementation based on whether users rather want to use locks or atomic swaps.

Additional context

I implemented a lock-free store in my alternative SDK here: https://github.com/mraerino/launchdarkly-rust-sdk-experimental/blob/main/src/store.rs On a large number of flags it will make a large number of allocations, since it deep-clones the map of flags on every update - that's a tradeoff of the lockless approach. I think using an RwLock around the map would be totally fine too though.

[keelerm84]

Thank for you for these suggestions and ideas, as well as linking to your own SDK implementation. We have reduced the amount of locking required in our most recent beta release.