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 <[email protected]>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: [email protected] > > Visit our website at http://www.intraway.com > Proud to be an ISO 9001:2008 certified company >
