Commit graph

6 commits

Author SHA1 Message Date
Eric House
b26549e331 a bit of cleanup 2020-12-14 08:57:11 -08:00
Eric House
9fa23af6e0 retain thread->env mapping in DEBUG builds only
I'm keeping it AND asserting at every possible location that the env
passed all the way in is the same as what the mapping produces. If in
months I haven't seen a single crash then I can evaluate which way of
passing the env around is better. (It'd be code size vs. performance,
as the passing of env is noticably faster. Code size could be fixed by
turning 'XWEnv xwe,' into a macro that goes away on some builds.)
2020-04-26 13:39:21 -07:00
Eric House
2343c34a44 remove more use of thread->env mapping 2020-04-26 13:39:21 -07:00
Eric House
105e8e2623 add logging
Keep some stuff added to debug problem with dict checksums on server.
2019-01-05 18:54:48 -08:00
Eric House
cbb683fc74 fix env-mapping crash in jni due to race condition
As reported to google, dict iterator destruction was crashing due to a
race condition if it happened after a game using the same dict had been
closed since it needed a mapped env that the game closure would
remove. Fixed in two ways, one by adding the mapping prior to the code
that uses it (a common pattern: add happens many times, whenver it might
be needed, but remove only once), and second by passing env into the
code that was crashing.

The mapping stuff remains inherently racy and I'm not sure now how to
fix that. It depends on there being a place to unmap after which it's
guaranteed the mapped value won't be needed again. When two
objects (game and dict_iter in this case) map the same env/thread combo
there's a race.
2018-01-22 07:45:43 -08:00
Eric House
49242f78cf more script fixes; move jni code 2017-01-18 07:27:23 -08:00
Renamed from xwords4/android/XWords4/jni/jniutlswrapper.c (Browse further)