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: Residue, ElemDesc, ResNo, ElemNo (these all from the bottom of residue.h) The following don't appear to be a problem: OBElementTable, OBTypeTable, OBIsotopeTable On my branch (https://github.com/baoilleach/openbabel/tree/fixglobalstate) I think I've fixed the following: OBAromaticTyper, OBAtomTyper, OBPhModel Roger didn't anticipate multi-processor architectures and it looks like OBChainsParser and OBResidueData as well as those variables listed above do have a problem. It should be possible to fix, but perceiving residues (or reading PDB and also I guess MOL2) will cause problems right now. I haven't really looked at OBErrorLog, and my time is up right now. Have I missed any classes that you know of? David, do you have any test code that reads an SDF multithreadedly, that could be used to force segfaults? Regards, - Noel On 11 February 2017 at 21:08, Noel O'Boyle <baoille...@gmail.com> wrote: > 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 <baoille...@gmail.com> wrote: >> 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 <dk...@pitt.edu> wrote: >>> 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 Biology >>> University of Pittsburgh >>> >>> >>>> On Feb 7, 2017, at 5:20 AM, Noel O'Boyle <baoille...@gmail.com> wrote: >>>> >>>> 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 >>>> instantiated by a TypeThisMolecule() function in the global class. >>>> >>>> This is an API breakage, but only because these internal >>>> implementation functions were exposed. I think the time might be ripe >>>> for a couple of API cleanups, not for the sake of it, but where they >>>> limit or affect the toolkit's usage. >>>> >>>> Regards, >>>> - Noel >>> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
