-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Config is not thread-safe #4942
Comments
I am very interested in this. Can I help with this? |
I'd like to get someone (@magik6k? @schomatis?) to comment on the design first. |
Looks good to me |
@chenminjian then go ahead. |
OK. |
SGTM |
This SGTM but I would need to see how the implementation works out. |
This fixes the data-race in the config. Depends on: ipfs/go-ipfs-config#16. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. However, we'll still need the Clone function for the new `--dry-run` flag introduced in #5455. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
@Stebalien Is this blocked by #5634 or can @chenminjian still attempt a fix here? |
Not really. That fixes the thread-safety issue but still doesn't allow for atomic config updates. For that, we need this change (so we can apply transformations while holding a lock on the entire config. |
Really, I'm not sure if there is a thread-safety issue anymore (if ever?). However, having a way to clone the config is still useful. |
Ok, pinging @chenminjian then, as he seemed really interested in this and has already landed some pretty useful patches regarding the |
This fixes a data-race in the config. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
Digging that PR back up, it looks like it addressed two separate issues:
|
This fixes a data-race in the config. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
This fixes a data-race in the config. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
❤️ Thanks for pinging me. I watched go-ipfs, so I didn't notice this email immediately. |
This has been implemented in the latest |
This fixes a data-race in the config. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
This fixes a data-race in the config. This does not fix #4942 as there's still a logical race: parallel config updates clobber each other. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
While we try to make it thread-safe by copying the config on read (see
Repo.Config()
) this doesn't really fix the problem because we have, e.g., maps inside of it. Furthermore, while not safety issue, the profile apply commands don't compose atomically.Instead of exposing
Config()
,SetConfig()
,BackupConfig()
, etc., we should probably provide the following two methods:The text was updated successfully, but these errors were encountered: