I'm considering a design for Subversion where in the single-threaded
environment, a pool is created and some user data is stored in it.
Then, in the multithreaded environment, many threads can get (but not
set) userdata within that pool.
In the current implementation, that should be safe; apr_hash
Although Subversion tries hard to avoid the use of global or process
state in its code base, on two occasions it has been forced to delve
into that realm: once to avoid the performance overhead of creating
frequent character-set translation contexts (passing a translation
context everywhere would h
On Fri, 2005-04-15 at 15:45, Peter N. Lundblad wrote:
> This idea is so simple and ellegant! My only concern is about contention
> if that function is used much (say every function in a library has to use
> it to ensure it was initialized). That might be over-paranoid, however.
Well, when possible
On Tue, 2005-05-31 at 11:18 -0500, Ben Collins-Sussman wrote:
> In any case: I'm wondering if we should be passing APR_LARGEFILE to
> all apr_file_io calls. Is it necessary? Should we expect problems
> if we don't?
Passing APR_LARGEFILE does not magically change the size of apr_off_t;
it do
On Tue, 2005-05-31 at 11:49 -0500, Ben Collins-Sussman wrote:
> Okay, so then there really is a risk here for very large
> repositories, particularly ones using FSFS.
It doesn't matter how large the repository is, only how large the
commits to it are.
> Should we start recommending that such pr
While reviewing the "APR-util UUID generator broken" thread, I noticed
the following code:
-get_system_time(&time_now);
+time_now = apr_time_now();
srand((unsigned int)(((time_now >> 32) ^ time_now) & 0x));
return rand() & 0x0;
Regardless of how time_now is determin
On Tue, 2006-04-18 at 09:43 +0100, Joe Orton wrote:
> That code is only a fallback for when no external/OS-provided UUID
> generation is used, and apr_generate_random_bytes() is not available or
> fails. Any modern Linux/BSD platform will satisfy the first constraint
> (with APR 1.0.3 and later
On Tue, 2002-07-16 at 21:14, Branko Čibej wrote:
> Strictly speaking, Ulrich's patch is better, because there's no
> guarantee that "errno" is a simple global variable. It could be
> translated into a function call, for all you know -- depends on the
> platform, linc implementation, threading su
On Wed, 2002-07-17 at 17:33, Ulrich Drepper wrote:
> You will always end up with two calls to 'foo' since the compiler is not
> allowed to eliminate them. It has no means to determine that 'foo' has
> no side effects and a constant return value.
I'll try once more, having been seemingly ignored l
The following program demonstrates a bug in APR: when a process is
created, it explicitly runs pool cleanups. I'm not sure what the
motivation for that is, but it's a bad idea. Note how "testdata\n" is
written twice to the file "test" when the test program is run, because
the apr_file_t output bu
On Wed, 2002-11-13 at 11:26, [EMAIL PROTECTED] wrote:
> This has been mentioned before -- at least by myself, perhaps by
> others, too -- but the Subversion folks would *really* like to see APR
> grow a gimme-a-temp-directory function.
Would gimme-a-temp-file be a better interface? Like mkstemp()
In the rev 1.10 of apr_poll.h (which is current on the release
branch), the following functions are marked deprecated:
apr_poll_setup
apr_poll_socket_add
apr_poll_socket_mask
apr_poll_socket_remove
apr_poll_socket_clear
apr_poll_revents_get
The deprecation comment is:
* @deprecated
I'm going to propose fixing apr_off_t at 64 bits regardless of the
system off_t. This is not about getting large-file support in APR,
although that could come as a side-effect; this is about helping
APR-using libraries to be compatible with two different universes of
libraries, and making APR itse
(Please keep me cc'd on replies, incidentally.)
Joe Orton wrote:
> I think the best way to achieve this is to define apr_off_t as
> off64_t on such platforms, rather than unconditionally change
> apr_off_t everywhere, and add LFS support to APR: most of this work
> is already done inside #ifdef NE
On Tue, 2004-01-27 at 05:49, Joe Orton wrote:
> > Won't that create an ABI time bomb for platforms which have no
> > large-file support now, but acquire it in the future?
>
> That's asking for a level of ABI guarantee which I don't think APR can
> provide regardless of this apr_off_t issue.
>
> W
On Wed, 2004-01-28 at 13:00, Kean Johnston wrote:
> > That looks great: I'll commit your patch to the 0.9 branch unless there
> > are any objections. Thanks a lot for working on this issue.
> My personal opinion is that its approaching the issue the wrong way. I
> think first and foremost, we nee
On Wed, 2004-01-28 at 17:34, Joe Orton wrote:
> One possible minor issue with this patch:
>
> if a C++ library based on APR uses apr_off_t in its API, I believe that
> changing apr_off_t from a long to an int changes the ABI of that
> library, because of the name mangling stuff.
To clarify, this
On Thu, 2004-01-29 at 06:32, Joe Orton wrote:
> Not sure what you mean by "APR code"... it would happen if the C++
> library exposes apr_off_t in its own API:
Yes, you're right; Ben corrected me on this over IRC. Sorry to confuse
the issue.
(What I was talking about was taking some or all of the
APR's handling of seeks to APR_END in buffered files has a sign error.
I've included a patch (see the end), and a test case.
I verified that nothing in Subversion or httpd uses APR_END, so it
seems likely that nothing is relying on the sign error. And the
documentation of apr_file_seek is very cl
On Fri, 2004-04-30 at 18:58, Joe Orton wrote:
> On Thu, Apr 29, 2004 at 10:44:16AM -0400, Jeff Trawick wrote:
> > wow
> >
> > is there any chance you can merge your test case into the existing test
> > suite?
Index: file_io/os2/seek.c
=
In case rbb's forward was too cryptic, I think the chief problem is
that file_io/unix/mktemp.c:gettemp() (which is not generally used on
Unix since APR uses mkstemp() there) does a direct comparison with
APR_EEXIST instead of using APR_STATUS_IS_EEXIST. So on Windows, APR
winds up returning a "fil
Imagine a library downstream from apr (say, Subversion) is trying to
follow the APR versioning guidelines
(http://apr.apache.org/versioning.html) in order to provide a stable
platform for third-party applications and libraries.
To do this, the downstream library must define the major version of
it
On Wed, 2004-06-30 at 04:56, Joe Orton wrote:
> > Install apr-config as apr-$(APR_MAJOR_VERSION)-config ?
>
> Greg wrote "remove" rather than "rename", though indeed, I guess
> renaming should work.
Renaming is also fine.
On Thu, 2004-07-01 at 10:30, Joe Orton wrote:
> Installing ap[ru]-$N-config alongside ap[ru]-config is probably all
> that's going to be feasible for the 1.0.0 release, at least I don't have
> time to deal with the fallout of removing ap[ru]-config entirely right
> now.
Hm. That's disappointing;
On Thu, 2004-07-01 at 10:39, Joe Orton wrote:
> This is done on HEAD: patches welcome for below to expedite removal of
> ap[ru]-config.
>
> > The AP?_FIND_AP? macros in find_ap?.m4 need to be adjusted to take a
> > minimum required library version argument, there's probably more...
Would it be ok
Joe Orton wrote:
> If apr-config is not renamed in the 0.9 branch (which is really
> required for compatibility), then I guess yes, make the argument
> optional, and have logic:
> AP?_FIND_AP?(without extra version argument)
>=> use apr-1-config if found else apr-config if found
> AP?_FIN
[EMAIL PROTECTED] wrote:
> >Please fix the makefile to set correct permissions.
On Thu, 2004-08-12 at 09:47, Bruce Elrick wrote:
> umask is considered a 'local' setting; there are many reasons to set it
> to various values depending on your local circumstances. It would not
> make sense to set
> Currently, one must path *both* a short-options string and an array
> of apr_getopt_long_t structures to apr_getopt_long().
There's no redundancy here (short options aren't currently specified
in the long options array), but I suppose we could easily shoehorn
short options into the long options
> Okay. Anyway, I think it would be nice if, when a short and long
> option mean the same thing, they could be specified in the same
> place. :-)
> One way is to replace the `val' field in apr_getopt_long_t with this:
>/* An array of single-letter options, any of which is equivalent to
>
> If name is null, then there's no long opt. If val is null, then
> there are no short opts.
So if "val" is NULL, how does apr_getopt_long communicate to the
caller which long option was returned?
> Keep `val', but add const char *short_equivs, I meant.
Okay, so I think the current proposal, with a little renaming to make
everything simple and consistent, is:
typedef struct apr_option_t {
/** long option name, or NULL if none */
const char *long_name;
/** short option letters,
> Okay; +1 on `char short_name' instead of `char *short_names'. As
> Greg points out, for the rare exceptions, one can specify two
> apr_option_t structs.
> But, in that case, we don't need a short_name equiv field at all --
> we can just use the val field (as the code currently does), right?
Th
I'm a subversion developer, belatedly trying to update to the new apr
repository using anonymous CVS, and I can't get in. I do:
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs login
and give the password "anoncvs", and it says
cvs [login aborted]: authorization failed: server apache.org rejected ac
So, I'm having no luck getting at the new apr repository to construct
a proper patch. (If anyone answered my earlier question to the apr
list, then I missed it; are there archives for that list anywhere?)
In the meantime, here is my implementation of the new apr_getopt_long
interface for people's
Okay, here is my finalized patch for apr_getopt_long, to change over
to the new simplified interface and to support interleaved arguments.
Thanks, Greg, for clearing up how to do an anonymous checkout.
I have asked rbb for commit access, but this being Thanksgiving
weekend, I'm not sure if he'll b
> Could you write a log message to accompany the commit?
Oh, right. Same standards as subversion, I take it? It's at the end
of this message.
> There's also been talk about eliminating the redundant `opts' param
> to apr_getopt_long(). Did you not do that because you didn't want
> to mix two c
>> -char *const *argv;
>> +char **argv;
> Um. I don't think we can do this with argv. I'm surprised that it
> isn't "const char * const * argv".
We can do whatever we want with argv. That's pretty well-established.
It wasn't "const char *const *argv" before because a "char **"
argument
>> It wasn't "const char *const *argv" before because a "char **"
>> argument is not compatible with such a parameter, and C programs
>> canonically take "char **argv", not "const char *const *argv". I'm
>> not sure if it's even valid C to silently change from char * to const
>> char * without an
> so I went for clarity and renamed it `apr_longopt_t'
I'm sorry to have disappeared, but I think this really needs to change
back (or to something else; I had picked apr_getopt_option_t).
Something that specifies both long and short options should not be
called "longopt".
Two changes here:
* apr_longopt_t gets renamed to apr_getopt_option_t.
* argv is accepted as a "char *const *argv", and we make a
copy in order to permute it. This is a compromise. The
parameter to be compatible with the argv value passed to
main, s
> Given the interface we've decided on, the copying of argv seems
> inevitable
Speaking of which, one more itty bitty little tweak I just thought of:
the argv array is traditionally NULL-terminated as well as counted,
and we should preserve that property in the copy. This isn't
particularly time-
> Const doesn't change the type (storage size) of anything. So a
> callee can *always* add a const qualifier to its parameters, as long
> as it then keeps that promise to never modify the data.
This rule is too expansive.
A parameter of type "pointer to const foo" is always compatible with
an ar
APR's buildconf has (Greg Stein wrote this):
ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
This doesn't work for me; I have libtool installed with exec_prefix
different from prefix.
Here is my proposed fix. It's much grosser in that it parses
human-readable libtoolize output whi
> /usr/include/sys/socket.h:47: syntax error before `sa_family_t'
> [etc.]
The problem is the -D_POSIX_SOURCE which Greg Stein added last night.
I was thinking of sending mail about it at the time, but decided he
had probably done all the necessary footwork; I guess he missed
something.
If you de
> I spent a good amount of time trying to figure out the right
> combination to allow us to include and (which
> is done by apr_want.h) without some redundant declaration warnings.
Can we change apr_want.h not to include if
APR_HAVE_STRING_H is defined?
> Removing redundant-decl was the easy f
I don't have any problems with this patch, but... isn't APR's pool
system doing way too much work? If I were implementing it, I would just
malloc() a new block for each apr_palloc(), chain it into a list, and
free() all those blocks when the pool is cleared or destroyed.
Presumably the extra work
46 matches
Mail list logo
