Hi Alex, Sorry, took me a while to go through this. +1 for second option. We may want to add a clear explanation in comments why we add an addition method with a reference to jira too.
thanks, Dinesh. On Fri, Apr 12, 2013 at 3:04 AM, Nandika Jayawardana <jayaw...@gmail.com>wrote: > Hi Alex, > I think the second option [ having a second version of the methods ) is > more viable. > > Regards > Nandika > > > On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut > <alex.mant...@intraway.com>wrote: > >> Hi All >> >> I have a question... I've been trying to improve Axis2/C thread stability >> and noticed several issues with the hash interface... >> >> - In one of the issues I need to stop using an external passed >> environment for the hash (because it might create problems in multithreaded >> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634) >> >> - In the other issue I need to internally manage the keys used, to >> avoid problems related to the memory of the keys... ( >> https://issues.apache.org/jira/browse/AXIS2C-1632) >> >> The problem is that the solutions I've found break backward compatibility >> (i.e. if I manage the key memory internally and the application allocated >> and freed the memory before it will create a double free problem)... >> >> I've managed to modify all the calls to the hash's methods in axis, but >> applications (like WSFCPP) might have a problem if I change the interface... >> >> My question would be, what is the better way to overcome this problem? >> >> Can I create a second version of the hash like axutil_hash2? >> >> Or can I create a second version of the methods whose interface changes >> (keeping them in the same file as hash)? i.e >> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry? >> >> As always thanks for your patience... >> >> Regards >> >> -- >> -- >> Mantaut Alex >> Intraway Corp. >> >> +54 (11) 6040-4000 >> MSN: alex.mant...@intraway.com >> >> Visit our website at http://www.intraway.com >> Proud to be an ISO 9001:2008 certified company >> > >
