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 returning it directly, so two simultaneous matches against the same pattern will confuse things. I'm not sure of the exact details of a solution until I study the existing code, but it will involve separating the parsed smarts pattern data structure from any match results and I'm guessing this will need an API change.
- Noel On 12 February 2017 at 20:18, Noel O'Boyle <baoille...@gmail.com> wrote: > ...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
