-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent concurrency issues #1
Comments
I am not sure what the goal is.
|
I think there should be at most 1 writer that can be shared (i.e. it can be |
The writer needn't be Syncing is not necessary, the data structure is built that it will only ever "see" completed writes while reading and it is append-only. So, in summary: Max 1 writer, total, not thread-safe but |
Would RwLock be of any help in that? Its kind of a Mutex which allows to acquire N readers but only 1 writer at a time. |
There needs to be some mechanism, either at compile- or runtime that prevents some basic errors to be made, like opening two writers to the same database.
Currently, I am thinking of the following semantics:
This should be enforced across threads, but not processes (i.e. we're assuming we are the only application using the database, no lock files or similar needed).
Making sure the database is not
Sync
is probably the first step (it should beSend
though?). Then, a runtime check, possibly through a wrapper type that Derefs, should be implemented, ultimately resulting in an instance ofutimeseries::err::Error
.An alternative would be just using a Semaphore(1) / Mutex on an internal field to track writers, but that'd make the database a little less flexible down the road.
The text was updated successfully, but these errors were encountered: