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
