Re: [OpenBabel-Devel] Race conditions

Actually, I think I've sorted it now, without any changes to OB. I realised that obLocale reference counts (like BeginModify) and does nothing if the locale is already set. See https://gist.github.com/baoilleach/1a7e517798804bdd96b3e9b4927092ce My earlier mention of a segfault within OBMol was

Re: [OpenBabel-Devel] Race conditions

On 19 February 2017 at 21:01, Geoffrey Hutchison wrote: >> Does anyone know exactly what problem the locale stuff is fixing? And >> a follow-on, is there another way to fix it? > > The problem is that we parse things like decimals for coordinates (0.) > which exist

Re: [OpenBabel-Devel] Race conditions

> Does anyone know exactly what problem the locale stuff is fixing? And > a follow-on, is there another way to fix it? The problem is that we parse things like decimals for coordinates (0.) which exist in the C locale. So we need to make sure the parsing code works in C locale not any other

Re: [OpenBabel-Devel] Race conditions

After making the changes to use the alternative thread-safe Match function, the next failure is with obLocale which is another global. Commenting out "free (d->old_locale_string);" semi-works around it for now (with a memory leak) but it can still segfault elsewhere in the locale code. Does

Re: [OpenBabel-Devel] Race conditions

I've just realised that David Koes has already fixed this, by providing just such an interface, a Match function where you pass in the vector for storing the matches. I owe you a pint or two, David. Note to self: as part of the API cleanup, we should remove the other functions. - Noel On 19

Re: [OpenBabel-Devel] Race conditions

I've made progress, but my current problem is that it's not possible to match the same SmartsPattern on different threads (as required, for example, by the typers, where sets of smarts patterns are initialised once and then reused). The matchers store the results as part of the pattern instead of

Re: [OpenBabel-Devel] Race conditions

...googling through the mailing list, I see that David Lonie mentions that OBErrorLog has problems, and Tim that all formats are singletons. I need to think some more about this latter. - Noel On 12 February 2017 at 16:45, Noel O'Boyle wrote: > Classes or variables with a

Re: [OpenBabel-Devel] Race conditions

Classes or variables with a global instance are susceptible to multithreading problems. It turns out that these are listed in the Python bindings. Classes: OBElementTable, OBTypeTable, OBIsotopeTable, OBAromaticTyper, OBAtomTyper, OBChainsParser, OBResidueData, OBPhModel, OBErrorLog Variables:

Re: [OpenBabel-Devel] Race conditions

Here's of what I was thinking: https://github.com/baoilleach/openbabel/commit/697b92180f9f61f738ef3e5c04d30340b9f8ee8e If it looks okay, I can make a similar change to other classes that have the same problem (assuming one size fits all). - Noel On 8 February 2017 at 09:32, Noel O'Boyle

Re: [OpenBabel-Devel] Race conditions

There's no memory overhead on the molecule class - it's unchanged. Let me make the change on a branch for one of the classes, and we can chew it over. - Noel On 7 February 2017 at 13:35, Koes, David wrote: > I think this is most definitely the way to go if you can tolerate the

Re: [OpenBabel-Devel] Race conditions

I think this is most definitely the way to go if you can tolerate the API changes. The main drawback is potentially each molecule class taking up more memory. I would welcome any changes that push openbabel closer to thread safety.. David Koes Assistant Professor Computational & Systems

[OpenBabel-Devel] Race conditions

Hi there, Wouldn't a better solution to the race conditions that David Koes is experiencing with global state be to remove the global state? For the cases he mentioned, e.g. the OBAromTyper, the global state relating to a single molecule can easily be moved to a OBAromTyperPrivate class