Avoid data race warning in SmilesParse.cpp

[skearnes]

This PR avoids a data race identified by TSan in SmilesParse.cpp. I'm not sure it's the best solution---the race could still exist if multiple callers of {Smarts,Smiles}ToMol use different settings for debugParse---but it avoids the issue in the usual case of repeated calls to {Smarts,Smiles}ToMol with the same params.

[bp-kelley]

Yeah, the yysmiles_debug is certainly not thread safe. I practice though I doubt one would ever get a data race. I'm tentatively ok with this solution, the only other one I can think of is to pass the SmilesParserParams object to all the functions, but this seems like a big rewrite.

[greglandrum]

Agreed: I see that this is not thread safe - in the event that everyone was ever actually running the parser in debug and non-debug modes simultaneously in separate threads - but I don't see how the proposed solution helps with any possible race condition.

If this is something we actually choose to worry about, we could add a mutex around yysmiles_debug, but I know that's going to make some folks unhappy.

[skearnes]

Agreed that this PR doesn't fix the race, but it does make TSan happy in the case of not changing options :)

[greglandrum]

LGTM
@bp-kelley : please merge if you agree

[bp-kelley]

Let’s at least add a doc note that params.debugParse Shouldn’t be used when multi threading. I can push a commit if you like.

[greglandrum]

I think It’s fine to use it multithreaded, you just shouldn’t us different values on different threads

[skearnes]

I can adjust the comments I added here to make this clearer...just a sec.

[skearnes]

There you go; PTAL.

[greglandrum]

Great. Thanks