Sam has asked that some Android devs who have an idea of JNI (which doesn’t include myself, sadly) might have a look at how to solve http://bugzilla.libsdl.org/show_bug.cgi?id=1422 sanely.
The problem is that SDL_RWops on Android cannot be used from any thread other than the main thread, so it is e.g. impossible to use them from the sound thread for streaming sounds from the assets, as an example (since I think SDL_RWops is the only way to access the assets on Android without extracting them to the sdcard first or some other ugly workaround).
For my personal situation (I am trying to do streamed sound on Android from the assets), required would be:
- SDL_RWops can be created from any thread
- Once created, an SDL_RWop object can be used from any thread (not just the one that created it), but calling it at the same time from multiple threads is not necessarily safe
Nice to have would be probably to avoid crashes and other nasty things even if read is done on an SDL_RWops even at the same time from multiple threads.
Now, there seems to be a patch that solves some or all of this: http://bugzilla.libsdl.org/show_bug.cgi?id=1159
However, the patch doesn’t cleanly apply (and I failed with my limited JNI knowledge to make it work - while I managed to make it compile in a way that seemed to be more or less senseful to me, it simply didn’t work at runtime). Also, according to Sam, the patch adds a large performance penalty.
So a nice solution that can go into mainline without performance penalty for those who don’t use threading would be good. But personally, I’d also love a compile-time switch enabled, slow performance version that can be enabled by people like me who need it - which that patch would be essentially, in case it worked.
I tried to work around this limitation purely application-side with lots of mutexes and locking and redirecting file access to the main thread, but it doesn’t work too well (very, very slow and delayed). Something inside SDL that makes threading SDL_RWops work sanely on Android would be much better.
Is there someone with JNI knowledge floating around who might want to share a few ideas or suggestions?------------------------
My Blog: http://gamedev-couch.blogspot.com/