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

InitGlobalBox is both not thread-safe and unclear about when and where it should be called #7

Open
puellanivis opened this issue Sep 10, 2022 · 0 comments

Comments

@puellanivis
Copy link

There is no global mutex lock on changing the value of the global in InitGlobalBox and as such, is open to race conditions.

It also remains unclear when and where it should be called from. If I import two libraries, apples and bananas both of which use the global pandora box, which of them is suppose to make this call to InitGlobalBox? Or is neither supposed to call it, and it is my duty as the top-level code to call it? If so, how can either apples or bananas guarantee that the init has been called?

Couldn’t this be a simple func init() { … } to ensure that it is called once at initialization of the program before any importing packages has its own inits run, thus guaranteeing it is well-behaved? (Also, the init process is run single-threaded, meaning many things that would otherwise be race conditions do not happen. That is, a write-once/read-many variable can be written to without fear of racing reads.)

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

No branches or pull requests

1 participant