thread safety of cJSON

[patrickfrey]

It would be relatively easy to make cJSON thread safe. Just get rid of the global error variable passing a pointer to a context structure to the parser for the error info. I submitted a request that was ignored some years ago (around 2011). I therefore assume that it is not seen as an important issue. I patched my fork of cJSON to archieve threadsafety. But seeing, that it is so easy to add it, I would like to suggest it again.

[FSMaxB]

Thread safety is on my list for version 2. And although cJSON is not 100% thread safe at the moment, there is a section in the readme about how it can be used across threads safely.

https://github.com/DaveGamble/cJSON#thread-safety

If you use cJSON_ParseWithOpts and use return_parse_end, the global error variable is not used, so there is no issue there.

The other problems with thread safety is cJSON_InitHooks and setlocale. If you avoid these, cJSON is already thread safe.

[FSMaxB]

It might even be possible to fix the thread safety problem with the allocators with cJSON_Configuration outlined in #177 by passing allocators to the function that creates the configuration object.

And there is a reason why parse_buffer contains internal_hooks, because the internal functions don't access global variables. This only happens in the functions that are called by the user of the library directly, the public API. They act like an adapter so that the internal functions can be rewritten in a thread safe way, so in the future I just have to change the "adapter" functions, thereby changing the public API and making it thread safe.

[FSMaxB]

That doesn't fix the problems with setlocale though, but I think this is a non issue, because most people don't change that more than once at the beginning.