This is on top of #154. I felt that the point of that PR was to finally demonstrate how to do broadcasting and updating the db in a safe way. I realized while reviewing it that there was still unfinished business here so I went ahead and implemented the missing pieces: mark and unmark unused.
I also made the examples take Mutexs around KeychainTracker etc so the example code has to force itself to be thread safe. This demonsrates points where we are keeping a lock on the tracker or db for longer than necessary or not long enough.
I found two problems with the way we were doing things:
In the Commands::Send broadcast code we were creating a changeset before brodacasting and storing it after. This might be a mistake unless you are willing to keep the lock over the broadcast call because by the time the broadcast has finished another thread may have made stored something else before it (this could potentially leave the tracker in an invalid state).
I found that in the Sync commands we were indeed keeping a lock over an entire sync and had to be rejigged a bit by first collecting all the spks we are interested in into a Vec before passing them on.
So it turns out this path of not checking the validity of change sets does make things quite tricky.
LLFourn
commented
1 year ago
This is on top of #154. I felt that the point of that PR was to finally demonstrate how to do broadcasting and updating the db in a safe way. I realized while reviewing it that there was still unfinished business here so I went ahead and implemented the missing pieces:
markandunmarkunused.I also made the examples take
Mutexs aroundKeychainTrackeretc so the example code has to force itself to be thread safe. This demonsrates points where we are keeping a lock on the tracker or db for longer than necessary or not long enough.I found two problems with the way we were doing things:
Commands::Sendbroadcast code we were creating a changeset before brodacasting and storing it after. This might be a mistake unless you are willing to keep the lock over the broadcast call because by the time the broadcast has finished another thread may have made stored something else before it (this could potentially leave the tracker in an invalid state).Synccommands we were indeed keeping a lock over an entire sync and had to be rejigged a bit by firstcollecting all the spks we are interested in into aVecbefore passing them on.So it turns out this path of not checking the validity of change sets does make things quite tricky.
I think we should merge #154 first.