serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [serf-dev] [serf] r2489 committed - In preparation of serf 1.4.0, remove the get_remaining function from t...
Date Sat, 12 Sep 2015 12:08:49 GMT
[redirected to dev@serf]

On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <> wrote:

> > -----Original Message-----
> > From: [] On
> > Behalf Of
> > Sent: maandag 6 april 2015 11:25
> > To:
> > 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?

Assuming that is the case (or we wouldn't be in this situation), then let's
change how v2 is API-compatibly detected. Again, let's use read_bucket()
since it gives us a lot of flexibility and nobody has ever used it. Let's
define a "V2_API_BUCKET" type and then ask for bucket FOO to return one of
those. If FOO's type has a NULL read_bucket pointer, or returns NULL for
that bucket type, then it is V1. If FOO's type has been updated, then it
*can* return a V2 bucket (which does nothing; could be a static const data

That will skip any function pointer comparisons. We *do* switch to a data
value (serf_bucket_type_v2_api), but I'm guessing Windows *does* have a
singular constant value for that within the program space.

Will this work?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message