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: [go] make staticData variable threadsafe #4489

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

Conversation

swist
Copy link

@swist swist commented Dec 13, 2023

I've hit a bug developing a go parser and running multiple instances of it with t.Parallel()

Turned out that staticData var was a global and would throw concurrent data access errors when running the test suite with -race

This commit fixes it by doing the following:

  1. turn <parser.grammarName; format="cap">ParserStaticData into a struct
  2. Teach <parser.name; format="cap">Init() to return a pointer to new instance of this struct
  3. Teach <parser.name; format="cap">Init() to initialize it upon construction
  4. Teach the parser constructor to use its own value for this var rather than a global
    I took similar steps for the Lexer

I've been able to run 10000 concurrent parsers in this setup without having any performance/memory usage problems

@swist swist changed the title fix: make static data variable threadsafe fix: [go] make static data variable threadsafe Dec 13, 2023
@swist swist changed the title fix: [go] make static data variable threadsafe fix: [go] make staticData variable threadsafe Dec 13, 2023
I've hit a bug developing a go parser and running multiple instances of it with t.Parallel()

Turned out that staticData var was a global and would throw concurrent data access errors when running the test suite with -race

This commit fixes it by doing the following:

1. turn <parser.grammarName; format="cap">ParserStaticData into a struct
2. Teach <parser.name; format="cap">Init() to return a pointer to new instance of this struct
3. Teach <parser.name; format="cap">Init() to initialize it upon construction
4. Teach the parser constructor to use its own value for this var rather than a global
I took similar steps for the Lexer

I've been able to run 10000 concurrent parsers in this setup without having any performance/memory usage problems

Signed-off-by: Tomasz Nguyen <me@swistofon.pl>
Signed-off-by: Tomasz Nguyen <tonguyen@confluent.io>
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.

None yet

1 participant