-
Notifications
You must be signed in to change notification settings - Fork 20
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
Thread safety (tests still missing) #41
Comments
That is a nice idea! |
Checklist for things that have come up:
|
you don't need to expose the internals really, you can just forward declare |
An alternative to bump to 1.0 is to do something like this inline void gbhw_setrate(int rate) { gbhw_state_setrate(&g_global_state, rate); } Now the old API can still work and it makes it possible for people to transition to the |
I foresee some problems with API stability and forward declaration of structs (currently code outside of gbhw accesses the channel data directly, this will probably need some new functions). So for now I created the new issue #42 to address the API stability. |
The new interface that basically encapsulates everything inside the |
The branch has been merged to master. |
Cool. Thanks! |
btw:
This would mean that we are thread-safe and re-entrant now, right? |
yeah, as long as the code only works with it's own owned data and doesn't modify global state it's all fine. To validate this is true the best way would be to write a test for it. The test could look something like this:
|
I had something in mind along these lines. |
Hi,
First of all thanks for a great library!
I wonder if there are any plans on making the code thread-safe? My use case is that I want to support play more than one song at a time (examples being cross fading, multi decode of many files at the same time, etc)
The current problem is that esp
gbhw.c
has lots of global variables. On way to solve this would be to setup a "state object" as the first parameter to allgbhw_
functions could take that instead of using the global variables. That way several threads can have their own "hardware" without conflicting with each-otherThe text was updated successfully, but these errors were encountered: