I've been working on this, and I don't see a solution. I have the parameter
added to child_init, and the structures get allocated. But, that doesn't solve
the problem, because many lock types just can't be used across an
apr_proc_create.
The only solution I can think of for this is to remove
On Thu, Jul 11, 2002 at 03:20:33PM -0700, Ryan Bloom wrote:
Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.
I'll agree that changing the typename doesn't solve the problem of
On Friday, July 12, 2002, at 07:05 PM, William A. Rowe, Jr. wrote:
At 08:49 PM 7/12/2002, [EMAIL PROTECTED] wrote:
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
but keep it ambigious and make no contract with the user
about the
units
Francisco, CA
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 11, 2002 4:41 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: apr STATUS
brianp 2002/07/11 16:40:48
Modified:.STATUS
Log:
Comments on the time_t discussion
The fact that APR has provided me with a platform-neutral way to get
high-resolution time has been a *huge* boon to my work. While I realize
this is a limited example, the same applies to many other use cases I can
think of.
Stop hand-waving-saying-we're-hand-waving, please. IMO there's
On Fri, Jul 12, 2002 at 12:13:54AM -, Justin Erenkrantz wrote:
jerenkrantz2002/07/11 17:13:54
Modified:.STATUS
Log:
IMHO, apr_time_t should be treated as an opaque value. The library should
be
free to change the implementation details whenever it wants.
There
On Thu, Jul 11, 2002 at 05:31:29PM -0700, Aaron Bannert wrote:
On Fri, Jul 12, 2002 at 12:13:54AM -, Justin Erenkrantz wrote:
jerenkrantz2002/07/11 17:13:54
Modified:.STATUS
Log:
IMHO, apr_time_t should be treated as an opaque value. The library
should be
On 12 Jul 2002 [EMAIL PROTECTED] wrote:
+ [fielding; Cliff says he has a sample app. I still don't know how
+ he uses them without making implementation assumptions about
+ apr_time_t everywhere (there is no print routine for microsecond
+ resolution), but I'll
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to understand the quantities, you must place
it through a function/macro. Brian has already converted httpd
to this model. -- justin
OK... after much hand waving
I will say the very same thing Ryan did several weeks [months?] ago.
Where were you for the last two years?
Complaining about how fucked up the design decisions were for apr_time_t.
Its in the archives. People didn't want to deal with it before due to
more pressing concerns. 2.0 is now out, so
Um, Roy? WTF are you talking about?
From apr/time/unix/time.c:
APR_DECLARE(apr_time_t) apr_time_now(void)
{
struct timeval tv;
gettimeofday(tv, NULL);
return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
And as for demonstrated needs, you're thinking too Apache-centric by a
longshot.
From: Roy T. Fielding [mailto:[EMAIL PROTECTED]
Sent: 12 July 2002 04:20
I will say the very same thing Ryan did several weeks [months?] ago.
Where were you for the last two years?
Complaining about how fucked up the design decisions were for apr_time_t.
Its in the archives. People
Irrelevant. If you want httpd to use APR, then it had better not make
httpd
worse for no good reason. If there is a reason, then I want it
documented
in the code. If not, if it is just the whim of some folks using APR,
then
I will fork the httpd project away from APR.
Roy, isn't this a bit of
It isn't supposed to be funny. I want to know why APR folks seem to think
that other applications of APR are as important, or even remotely as
important, as the performance of httpd. I want to know because all of the
decisions
that have been made in the name of other application's needs
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to understand the quantities, you must place
it through a function/macro. Brian has already converted httpd
On Thu, 2002-07-11 at 17:22, Ryan Bloom wrote:
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to understand the quantities, you must place
it through
From: Brian Pane [mailto:[EMAIL PROTECTED]
On Thu, 2002-07-11 at 17:22, Ryan Bloom wrote:
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to
At 07:22 PM 7/11/2002, Ryan Bloom wrote:
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to understand the quantities, you must place
it through a
Ryan Bloom wrote:
Can we start this conversation over completely?
I think we just did that yesterday. :-)
Currently we are
arguing over names for a new type, but I don't think we actually know
the problem that we are trying to solve.
The problem is that don't have a consensus on whether to name
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t [binary microtime].
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs out there that use APR's
apr_time_t and will
At 02:20 PM 7/11/2002, Aaron Bannert wrote:
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs
On Thu, Jul 11, 2002 at 02:35:04PM -0500, William A. Rowe, Jr. wrote:
In this case, semantic compatibility has NO IMPACT on binary
compatibility. The code will remain binary compatible, even though
this change breaks the behavior.
APR changes... we are pre-1.0 and our developer/consumers
William A. Rowe, Jr. wrote:
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t
On 11 Jul 2002 [EMAIL PROTECTED] wrote:
+ -1: aaron [veto for reusing the apr_time_t identifier for a new
use.
+I'm ok with apr_timeval_t.]
If we're avoiding apr_time_t because of confusion with the POSIX time_t,
it makes no sense whatsoever to use
On Thu, Jul 11, 2002 at 01:37:14PM -0700, Brian Pane wrote:
Let's take a typical scenario:
- Acme software releases mod_acme 2.0 to work with Apache 2.0
- They distribute a binary version of this module to work specifically
with 2.0.39 (the only version out that isn't susceptible to the
Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.
I'll agree that changing the typename doesn't solve the problem of
mismatched binary compatibility, but it does make it obvious to the
app
Ryan Bloom wrote:
Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.
I'll agree that changing the typename doesn't solve the problem of
mismatched binary compatibility, but it does make it obvious to
Are these also for consideration in the 2.0.34 release?
Bill
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
experienced with flock and SysV sems.
Revision
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Are these also for consideration in the 2.0.34 release?
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
[EMAIL PROTECTED] writes:
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
experienced with flock and SysV sems.
I just committed a fix for flock-based
[EMAIL PROTECTED] wrote:
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
experienced with flock and SysV sems.
I'll update this as appropriate after
From out in left field... this was sitting amidst my drafts. Dunno how
relevant it still is.
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Tuesday, February 05, 2002 10:30 AM
On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote:
On OS/2 the only native mechanism that has
On Mon, 4 Feb 2002 11:17:38 -0800, Aaron Bannert wrote:
Can someone please comment on the state of the OS/2 and Netware lock
implementation? Is it unnecessary or even senseless to implement
a cross-process lock on Netware (where I've been told there are
only threads)?
On OS/2 the only native
On Fri, Dec 21, 2001 at 07:57:38AM -0500, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
jerenkrantz01/12/12 02:05:54
Modified:.STATUS
Log:
Not a big deal, but worth noting. If anyone has an idea on how to
detect this, it'd be general goodness to error out
Justin Erenkrantz [EMAIL PROTECTED] writes:
Maybe we should try to acquire/release the lock during create time,
and return the acquire errno if that fails. Maybe the error codes
differ between systems but at least we fail ahead of time.
That sounds easy and harmless to me. Any
On Tue, Dec 25, 2001 at 08:19:19PM -0500, Jeff Trawick wrote:
I'd like to see this as a lock creation option. Something like
a flag - say, APR_LOCK_VERIFY or some such. I don't think we should
do the acquire/release unless asked for by the caller. I think
this might mean changing or
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Tue, Dec 25, 2001 at 08:19:19PM -0500, Jeff Trawick wrote:
I'd like to see this as a lock creation option. Something like
a flag - say, APR_LOCK_VERIFY or some such. I don't think we should
do the acquire/release unless asked for by the
On Tue, Dec 25, 2001 at 09:47:12PM -0500, Jeff Trawick wrote:
Other than performance, why should the caller care? The lock can't
block. Unbeknownst to the caller we or libc get locks on other
callers.
Still curious,
Hmm. Let me try and restate it. It's a feeling that doing this
would be
[EMAIL PROTECTED] writes:
jerenkrantz01/12/12 02:05:54
Modified:.STATUS
Log:
Not a big deal, but worth noting. If anyone has an idea on how to
detect this, it'd be general goodness to error out when we create
the lock rather than waiting to error out when
[EMAIL PROTECTED] wrote:
And, you thought there wasn't going to be anything happening with this
item (FreeBSD and threading support)? Ha!
+Status: Justin has tracked down a FreeBSD kernel hacker
+([EMAIL PROTECTED]) and we've isolated some issues
+
On Thu, Aug 23, 2001 at 04:03:37AM -, [EMAIL PROTECTED] wrote:
...
@@ -100,6 +104,7 @@
built-in macro processing is much more powerful, and
combined with the include facility, generating Makefiles
becomes simpler and faster.
+
ALLOC_USE_MALLOC would be faster than the current pool code for
a threaded APR (but, I'm not sure).
Status: Justin volunteers
+David and Sander are working on some stuff that
+should be ready Real Soon Now (TM). Sander has
On Wed, Jun 27, 2001 at 10:17:40PM -0700, [EMAIL PROTECTED] wrote:
Not to be contrary, but this can be easily resolved, by passing in a
simple flag when creating a pool. That flag tells us whether or not we
should lock when using the pool.
The real point is that we have a global freelist.
Right. What Cliff said.
We aren't going to provide a replacement for it, just say whether it is
available, and get it linked in from the right library (it can live in
several places).
crypt() is a rather poor hash function. We have MD5 and SHA1 instead.
Cheers,
-g
On Thu, May 31, 2001 at
On 31 May 2001 [EMAIL PROTECTED] wrote:
@@ -65,6 +65,8 @@
* add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
crypt() function is available, and a way to call it (whether it is
located in libc, libcrypt, or libufc)
+ Justin says: Should
On Thu, May 31, 2001 at 12:14:02AM -0400, Cliff Woolley wrote:
On 31 May 2001 [EMAIL PROTECTED] wrote:
@@ -65,6 +65,8 @@
* add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
crypt() function is available, and a way to call it (whether it is
On Wed, 30 May 2001, Justin Erenkrantz wrote:
I think that wherever these other crypto functions go, so should
crypt().
Yeah, but...
crypt() is slightly different than the other crypto algorithms as
my systems have it as a standard library call. But, not all systems
will have it.
Which
[EMAIL PROTECTED] wrote:
+* add a pool argument to setaside() to tell a bucket do whatever
+ you need to do, to ensure that you survive as long as this
+ pool. Immortal and heap buckets never have work. File, socket,
+ mmap, pipe, and pool buckets can do nothing if
On Fri, 27 Apr 2001, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
+* add a pool argument to setaside() to tell a bucket do whatever
+ you need to do, to ensure that you survive as long as this
+ pool. Immortal and heap buckets never have work. File, socket,
+
[EMAIL PROTECTED] wrote:
On Fri, 27 Apr 2001, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
+* add a pool argument to setaside() to tell a bucket do whatever
+ you need to do, to ensure that you survive as long as this
+ pool. Immortal and heap buckets never have
+* I think apr_open_stderr() and friends dup() the descriptor. That
+ would allow the new/returned file to be closed (via pool cleanup
+ or manually) without accidentally closing stderr/out.
The goal of those functions is to actually get stderr, stdout, stdin
+* I think apr_open_stderr() and friends dup() the descriptor. That
+ would allow the new/returned file to be closed (via pool cleanup
+ or manually) without accidentally closing stderr/out.
The goal of those functions is to actually get stderr, stdout, stdin into
an
Are we not using it as we haven't come across the case where we need it yet?
If that's the case then I'll remove my +1 but from the note it looked as if
we just weren't ever using it.
david
@@ -62,7 +62,13 @@
- It ignores the type parameter, so toss it.
- The fname param
On Sun, 28 Jan 2001, David Reid wrote:
Are we not using it as we haven't come across the case where we need it yet?
If that's the case then I'll remove my +1 but from the note it looked as if
we just weren't ever using it.
We aren't using the type parameter because nobody has had the time to
+++ STATUS 2001/01/18 02:25:06 1.22
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
Those for adding apr/src/: gstein, jim, brane
+ Those for removing apr-util/src/ : wrowe, rbb, dreid, stoddard,
fielding
I have completed this task. Ryan
I'll get this building again now. I just have to update my local copies.
Ryan
On Wed, 17 Jan 2001, William A. Rowe, Jr. wrote:
+++ STATUS2001/01/18 02:25:06 1.22
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
Those for adding apr/src/:
Nevermind, there was nothing to do. Good job Will. :-)
Ryan
On Wed, 17 Jan 2001 [EMAIL PROTECTED] wrote:
I'll get this building again now. I just have to update my local copies.
Ryan
On Wed, 17 Jan 2001, William A. Rowe, Jr. wrote:
+++ STATUS 2001/01/18 02:25:06
brane 01/01/14 16:28:05
Modified:.STATUS
Log:
This vote ends on Wednesday ... which wednesday?
This Wednesday, later tonight (once we have one vote more or less).
At 10pm CST (so I can get to work.)
These have sat in status well over two months, anyone who doesn't
Wow, either my plea for a vote worked, or we just got lucky. Thanks
Bill. :-)
Ryan
On 17 Jan 2001 [EMAIL PROTECTED] wrote:
stoddard01/01/17 12:39:28
Modified:.STATUS
Log:
Vote
Revision ChangesPath
1.21 +2 -2 apr/STATUS
Index: STATUS
Modified:.STATUS
+* apr_create_lock() changes:
...
+ - The fname param is allowed to be NULL on the Unix platform.
feature, not bug... Do you mean that the semantics associated with
this (make up a file for me if you need to, APR) are not implemented
Q. Now that APRUTIL exists, may we please move hooks (a
generally useful
entity) into that lib (and put this issue back into util?
I think we are just waiting for some people on dev to decide how to move
the code out of Apache and into apr-utils. Greg and I have both voted
Given the mapping you list below, are you considering a tighter
formalization of the namespaces *within* APR? For example, all file
functions would be apr_file_* ?
I'm -0 on that, but some targeted renames (like the one below) would be a
Good Thing.
Cheers,
-g
On Thu, Nov 30, 2000 at 04:03:50PM
Given the mapping you list below, are you considering a tighter
formalization of the namespaces *within* APR? For example, all file
functions would be apr_file_* ?
I'm -0 on that, but some targeted renames (like the one below) would be a
Good Thing.
Cheers,
-g
On Thu, Nov 30, 2000 at 04:03:50PM
64 matches
Mail list logo
