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

fix EOFError when execute targetcli commands concurrently #61

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

zoumingzhe
Copy link

fcntl.LOCK_UN means unlock, but save file must have the exclusive lock. So, we must use fcntl.LOCK_EX in here.

@zoumingzhe
Copy link
Author

zoumingzhe commented Oct 19, 2021

fix issue #60

@zoumingzhe zoumingzhe force-pushed the EOFError branch 4 times, most recently from f93901f to 9f31078 Compare October 20, 2021 12:00
1.fcntl.LOCK_UN means unlock, but save file must own the exclusive lock.
  So, we must use fcntl.LOCK_EX(acquire an exclusive lock) flag in here.
2.Then, fcntl.lockf is different from fcntl.flock:
  a)fcntl.flock always lock for the whole file
  b)fcntl.lockf can only lock part of the file
  c)see https://docs.python.org/2.7/library/fcntl.html for details
  I think is better to call fcntl.flock in here.
3.open file via 'wb' will truncate the file without lock protection,
  if load prefs.bin at the same time, maybe read empty prefs.bin and
  raise EOFError.
4.However the patch only avoid EOFError, prefs may be replaced with
  the default value if read file and truncate file at the same time.
  A new patch need to commit, and lock before open prefs.bin to
  solve the prefs consistency problem.

Signed-off-by: Zou Mingzhe <[email protected]>
@zoumingzhe zoumingzhe force-pushed the EOFError branch 3 times, most recently from 07ee724 to c7253b1 Compare October 21, 2021 15:42
…e at the same time

Open prefs.bin via 'wb' will truncate file without lock protection.
So read prefs.bin and truncate prefs.bin at the same time,
the preferences maybe replaced with the default value.
Add a prefs.lock file to guarantee the atomicity of save and load operation.

The patch can not solve old value read when targetcli command concurrency.
That is, if change preference at same time as execute another targetcli command,
next ConfigShell will load old prefs.bin file before previous ConfigShell save it.
To fix this problem, targetcli-fb:scripts\targetcli must be modified.

Signed-off-by: Zou Mingzhe <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant