Skip to content
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

Add file locking #12

Open
PicoJr opened this issue Dec 28, 2019 · 4 comments
Open

Add file locking #12

PicoJr opened this issue Dec 28, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@PicoJr
Copy link
Owner

PicoJr commented Dec 28, 2019

Currently there is no file locking.

Running several rtw commands may lead to undefined behavior.

@PicoJr PicoJr added the enhancement New feature or request label Dec 28, 2019
@maikwoehl
Copy link

If I have spare time this week, I can try to add file locking with https://docs.rs/fs2/0.4.3/fs2/trait.FileExt.html.

I need a tool for tracking the work on my bachelor thesis.

@nohupped
Copy link

If I have spare time this week, I can try to add file locking with https://docs.rs/fs2/0.4.3/fs2/trait.FileExt.html.

I need a tool for tracking the work on my bachelor thesis.

As per the flock man page,

Furthermore, the lock is released either by an explicit LOCK_UN operation on any of these duplicate descriptors, or when all such descriptors have been closed.

I believe the file locking with this trait won't work in this case because the program writes the status into ~/.rtwh.json and ~/.rtw.json and exits, thereby closing all the file descriptors and releasing the lock.

@maikwoehl
Copy link

Do it really need some file locking mechanism with the filesystem already enforcing exclusive write access to the file while executing multiple instances?

Or is this issue about a wait until unlocked and then get the lock?
Or is it about synchronizing the reads and writes like atomic transactions?

@nohupped
Copy link

Apologies, I was too soon to say that. As I ran multiple tasks manually, I realised that when a job is already in progress and another job is created, it gets appended to the "activities":[] list, so creating a new task while an existing task exists is not a problem. The only case of a race condition I can think of is when two rtw process starts at the same time and writes to the same file at the same file, which leads to undefined behaviour, which could be addressed by the https://docs.rs/fs2/0.4.3/fs2/trait.FileExt.html. trait. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants