...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 <baoille...@gmail.com> wrote: > 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
