On Sep 12, 2015 11:01 AM, "Ivan Zhakov" <[email protected]> wrote: > > On 12 September 2015 at 15:08, Greg Stein <[email protected]> wrote: > > [redirected to dev@serf] > > > > On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <[email protected]> wrote: > > > >> > -----Original Message----- > >> > From: [email protected] [mailto:[email protected]] On > >> > Behalf Of [email protected] > >> > Sent: maandag 6 april 2015 11:25 > >> > To: [email protected] > >> > Subject: [serf-dev] [serf] r2489 committed - In preparation of serf > >> 1.4.0, > >> > remove the get_remaining function from t... > >> > > >> > Revision: 2489 > >> > Author: lieven.govaerts > >> > Date: Mon Apr 6 09:24:18 2015 UTC > >> > Log: In preparation of serf 1.4.0, remove the get_remaining function > >> > from the > >> > bucket API. > >> > > >> > This reverts most of r2008, r2009, r2010 and r2198. From r2008 I kept the > >> > read_bucket_v2 function, which is needed for set_config. > >> > >> If we still keep the read_bucket_v2 feature, what is the reason for just > >> removing get_remaining? > >> > >> > >> We still have to handle the linkage problems if we use the > >> read_bucket_v2() system for versioning, but we leave out the tests that > >> were added to find problems caused by different function pointers. > >> > >> > >> The reason we see errors on this feature on several platforms is just this > >> linkage problem, while the get_remaining code itself is pretty stable as > >> far as I can tell. I'm guessing that the reason for removing the code is > >> that we see this errors. > >> > >> > >> Our scons scripts make us link both the static library and shared library > >> versions of the same functions, and then a simple pointer comparison on a > >> function pointer isn't going to work as expected. > >> > >> > >> And with a shared library build, there are other possible problems: > >> sometimes you get a pointer to a wrapping function... or the pointer value > >> is not guaranteed because the code might be moved under some circumstances > >> (unload+load of library) > >> > > > > So you're saying that a pointer to a specific function might have *two* > > values under Windows? Within a single executable? That A could see a > > different value from B? > > > This is not Windows specific problem, the original problem report was on Linux: > "Buckets v2 check doesn't work on Linux in the test suite > (test_aggregate_buckets fails)" [1] > > Bert commented that serf on Windows had similiar problems, but I > don't know details. > [1] https://issues.apache.org/jira/browse/SERF-134
That JIRA indicates there are multiple copies of the function, which is clearly wrong.
