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: use a sync.Map to prevent "concurrent map read and map write" fa… #1923

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tinmrn
Copy link

@tinmrn tinmrn commented Nov 18, 2024

…tal error when using "output: prefixed"

fixes #1922

@@ -85,11 +86,11 @@ func (pw *prefixWriter) writeLine(line string) error {
line += "\n"
}

idx, ok := pw.prefixed.seen[pw.prefix]
idx, ok := pw.prefixed.seen.Load(pw.prefix)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps LoadOrStore() is better than Load() and then Store()?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, that would be neater. But I will await the below discussion about sync.Map.


"github.com/go-task/task/v3/internal/logger"
"github.com/go-task/task/v3/internal/templater"
)

type Prefixed struct {
logger *logger.Logger
seen map[string]uint
seen *sync.Map
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we simply use a mutex for protecting the seen map? It's actively used in this project: 1, 2.

Suggested change
seen *sync.Map
muSeen sync.Mutex
seen map[string]uint

Additionally, sync.Map has drawbacks and rare use cases. See https://victoriametrics.com/blog/go-sync-map/

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the go docs of sync.Map:

The Map type is optimized for two common use cases: (1) when the entry for a given
key is only ever written once but read many times, as in caches that only grow,
or (2) ...

I think that applies here, because potentially a lot of lines get written and only relatively few prefixes will be used.

I think speed is important here since task execution blocks waiting for output to be written. But I have no strong opinion about either way, and we would have to benchmark to check which is actually faster.

One drawback of sync.Map over a mutex is that sync.Map is not type safe, but I think its usage is easy to oversee in this case.

Copy link
Contributor

@alexandear alexandear Nov 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we need to add a test case to ensure that this PR fixes an issue.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try to write one that is deterministic, but since this is a race condition i'm not sure that's possible.

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.

fatal error: concurrent map read and map write - in internal/output.(*prefixWriter).writeLine
3 participants