#define APR_FOPEN_SENDFILE_ENABLED 0x01000 /**< Advisory flag that this
file should support
apr_socket_sendfile
operation */
Is there a reason why this flag is not always enabled? If the OS
supports sen
Hmm, that's not the behavior I am seeing with Leopard's sendfile. I am
seeing the value-result parameter come back with the total byes in the
file plus the total size of the trailers, excluding the headers.
For example, with a header of 80,000 bytes, a file of 200,000 bytes,
and a trailer o
On Nov 1, 2007, at 6:08 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
We don't test sendfile by default. Within APR (trunk), simply...
$ cd test
$ make
$ ./sendfile server &
$ ./sendfile client blocking
and you'll see how either the kernel library or the implementation
(or m
Hi Everyone, I've been testing our code on Darwin 9/Leopard:
Good news: it works and we can actually create universal binaries:
.libs/libapr-1.0.dylib: Mach-O universal binary with 3 architectures
.libs/libapr-1.0.dylib (for architecture ppc7400): Mach-O dynamically
linked shared library ppc
.
On Wed, Apr 04, 2007 at 09:43:33AM +0530, Rashmi Badan wrote:
> Using the escape character \ to escape the single quote within the value
> string didn't seem to work - parser gives an error. Is there a way to go
> about this? Is there a way to tell the parse to escape the quote within the
> value s
On Thu, Aug 31, 2006 at 07:06:10AM +, Christian BOITEL wrote:
> Following my discussion on this topic with rpluem on bugzilla, i am posting
> this one to submit you a change in the reslit pool management to ensure
> proper pool size regulation and some API changes to better handle this part
Could you post the code that is failing?
-aaron
On Nov 15, 2005, at 11:58 AM, Daniel May wrote:
Neither apr_proc_mutex or apr_global_mutex seem to work under
Linux. I created a simple single instance case
where I created a named mutex in an test program and paused. I
started a second in
Have you looked at the apr_thread_cond_* API? These are
virtually identical to POSIX Condition Variables, and can
be used to do what you're talking about.
-aaron
On May 18, 2005, at 4:09 AM, Bruno Haas wrote:
I am quite surprised that there are no counting semaphores in apr.
What I would need to
wick wrote:
On Sun, 20 Feb 2005 14:58:16 -0800, Brian Ferris
<[EMAIL PROTECTED]> wrote:
I've been developing with the APR on Mac OS X 10.3.8, and I'm
...
The PTHREAD_RWLOCK_INITIALIZER macro is missing, which prevents the
unix rwlock implementation from kicking in. Changing it to som
This is a patch against the trunk that re-enables rwlock support in
APR on Mac OS X (Darwin). Apparently the PTHREAD_RWLOCK_INITIALIZER
is no longer part of the posix spec[1], and so it was completely
removed from
the pthread.h header on darwin. Since APR doesn't ever do static
initialization
of
+1 (seems to work fine on Solaris 9/x86)
-aaron
On Aug 26, 2004, at 1:09 AM, David Reid wrote:
new apr-util tarballs are now available at
http://www.apache.org/~dreid/
So far I've seen only 1 +1 for a release. Anyone else care to vote?
david
On Jul 2, 2004, at 12:43 PM, Craig Rodrigues wrote:
I maintain the port for apr in the FreeBSD ports collection.
The latest version of FreeBSD's implementation of threads is *MUCH*
more stable than in earlier versions of FreeBSD. To compile a program
for threads, all you need to do is link with -l
On Mar 15, 2004, at 11:30 AM, [EMAIL PROTECTED] wrote:
Yeah, but rather than add a showstopper, I am just going to fix this
today. It
is on my list of things to fix ASAP.
Part of me wishes we didn't have the lock mechanism in the
main apr_*_mutex_create() functions, so that they could just be
ful
On Mar 15, 2004, at 11:15 AM, Aaron Bannert wrote:
On Mar 15, 2004, at 10:56 AM, [EMAIL PROTECTED] wrote:
Nope. Take a look at the thread that is complaining about the API for
global_mutex and proc_mutex. Without that global_mutex_create call,
the program
segfaults on any Unix machine. This is
On Mar 15, 2004, at 10:56 AM, [EMAIL PROTECTED] wrote:
Nope. Take a look at the thread that is complaining about the API for
global_mutex and proc_mutex. Without that global_mutex_create call,
the program
segfaults on any Unix machine. This is a bug in the _child_init API,
because it
should ac
On Mon, Mar 15, 2004 at 09:13:34AM -0800, [EMAIL PROTECTED] wrote:
> I am trying to port the testgloballock code to the unified framework, and I
> can't make the child process work. It seems that apr_global_lock_child_init
> only works if the child process was created using apr_fork. This means t
On Thu, Mar 11, 2004 at 11:34:27PM +, Joe Orton wrote:
> On Thu, Mar 11, 2004 at 02:18:04PM -0800, Aaron Bannert wrote:
> > Are the showstoppers that are listed in the STATUS file the only
> > ones we have? (for APR, APR-UTIL, etc...)
>
[...]
> - fixing condition variabl
On Wed, Mar 10, 2004 at 06:06:16PM -0800, [EMAIL PROTECTED] wrote:
> APR-util needs a full test suite. I will try to put together the framework
> from
> the APR repository ASAP. probably sometime tomorrow. While I am at it I will
> start the test suite at the same time. I will be focusing on th
On Mon, Mar 15, 2004 at 03:37:42AM +, Nick Kew wrote:
> It's 3 in the morning again, but I've written an updated patch,
> This time I've adapted the testsuite to watch it in action and
> successfully run it (Linux 2.4.x). As ever, more eyes better:-)
Tested and committed. Thanks for the patch
On Fri, Mar 12, 2004 at 07:25:49PM +0100, Sander Striker wrote:
> I hereby would like to propose that we move APR to the Subversion
> repository at http://svn.apache.org/repos/asf/.
-1
I'm against immediate adoption of SVN for purely community-based
reasons, but not for technical reasons. I belie
Are the showstoppers that are listed in the STATUS file the only
ones we have? (for APR, APR-UTIL, etc...)
-aaron
On Fri, Jan 02, 2004 at 03:09:09AM +, Nick Kew wrote:
> Rationale: if an module gets a resource that proves to be bad (e.g.
> a connection that's gone away), it shouldn't be returned to the
> pool to be given out again. We should invalidate it.
>
> I'm proposing the following patch, though I'
On Fri, Feb 20, 2004 at 11:16:10AM -0800, Justin Erenkrantz wrote:
> It'd be trivial to have minotaur run ./buildconf before producing the
> snapshots. This would lower the barrier of entry on the snapshots: you'd
> no longer need autoconf, libtool, etc to use those. -- justin
Isn't libtool st
[we really should move this to the [EMAIL PROTECTED] list]
On Fri, Dec 12, 2003 at 11:53:53AM +, Ben Laurie wrote:
> This was exactly the conversation we were having at the hackathon. As
> always, Windows was the problem, but I thought Bill had it licked?
Well, there are two things we have t
On Dec 4, 2003, at 4:43 AM, Jeff Trawick wrote:
Lev Serebryakov wrote:
Is here any plans for relesa separate apr-0.9.5 or even apr-1.0
distribution?
AFAIK, there was plans to release apr-1.0 at 19/Nov/2003...
Is here any new timelines, etc?
I dunno about 0.9.5.
For 1.0:
The only issue I know
On Mon, Nov 17, 2003 at 06:11:06AM -0500, Joe Orton wrote:
> On Sun, Nov 16, 2003 at 06:25:00PM -, Jeff Trawick wrote:
> > trawick 2003/11/16 10:25:00
> >
> > Modified:locks/unix thread_mutex.c
> > Log:
> > thread id is not always a scalar
>
> This nested mutex code still relies
On Sat, Nov 15, 2003 at 03:58:55PM -0800, Sander Striker wrote:
> > If the RELEASE_VERSION is an optional parameter (in which case the
> > script would try to figure out the name of the tarball based on the
> > TAG) what happens when the TAG does not contain a version? Does it
> > fail? Want to wri
On Sun, Nov 16, 2003 at 03:19:42PM -0800, Justin Erenkrantz wrote:
> --On Sunday, November 16, 2003 8:37 PM + [EMAIL PROTECTED] wrote:
>
> >aaron 2003/11/16 12:37:07
> >
> > Modified:toolsrelease.sh
> > Log:
> > It now takes a CVS TAG *and* a RELEASE_VERSION.
> >The TAG is
I've updated the tools/release.sh script in the apr-dist CVS repository
to make it easier for anyone to create APR tarballs. Before it was
necessary for a tag to exist before a tarball could be created. This
made it very difficult to release experimental/developmental tarballs
to a set of users for
On Sun, Nov 16, 2003 at 03:13:21PM -0500, Jeff Trawick wrote:
> >+1 This is great, but will having to call a function negatively affect
> >performance?
>
> Of course :) Pick your poison.
Hmm...maybe we should compare performance of a functionized version
of atomics vs. doing the same using pthre
On Sun, Nov 16, 2003 at 03:05:59PM -0500, Jeff Trawick wrote:
> this will resolve two types of problems:
>
> 1) all implementations will then be required to use a single set of
> function prototypes, avoiding some problems we've had getting all platform
> logic to agree on what the prototype sho
On Nov 6, 2003, at 8:55 AM, Joe Orton wrote:
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote:
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
$ grep -l -r --include \*.c APR_IS_BIGENDIAN .
./random/unix/sha2.c
Ah, I didn't pi
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
-aaron
On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote:
> jorton 2003/11/06 01:18:22
>
> Modified:.configure.in
> Log:
> * configure.in: Fix endianness de
On Wed, Oct 29, 2003 at 08:57:27AM -0500, Ian Gough wrote:
> Hi,
>
> I have been given the task of determining the issues involved in porting
> our product to various 64 bit platforms but I couldn't find any
> supported 64 bit platform information at the APR home page. Actually, I
> couldn't find
On Thu, Oct 23, 2003 at 05:24:07PM -0400, MATHIHALLI,MADHUSUDAN
(HP-Cupertino,ex1) wrote:
> Hi,
> I was wondering if there's any interest in having a option to make
> the apr_thread_rwlock to support GLOBAL rwlocks. Currently,
> apr_thread_rwlock exhibits the default pthread behaviour - to b
On Wed, Sep 24, 2003 at 10:22:39PM -0500, William A. Rowe, Jr. wrote:
> Others responded, "lets ditch nested locks". I'm -0.5 on that suggestion.
Are there reasons we should keep it around? I didn't see any comment
from you for or against the proposal, and frankly I didn't get enough
positive or
On Friday, September 12, 2003, at 12:37 PM, Chris Knight wrote:
Alas, I do need a full-fledged pool interface (in fact, I need it to
be the same pool interface so I can hand it wrapped in an apr_pool_t
to apr_hash_create and the like.
Take a look at how mod_ssl-2.0 does this kind of stuff. It ma
If you don't need a full-fledged pool interface, but just malloc/free,
take a look at apr_rmm.h (in apr-util/include/). There's also an
exmaple in the apr-util examples, IIRC.
-aaron
On Friday, September 12, 2003, at 11:43 AM, Chris Knight wrote:
(If this has been discussed previously, I apologize
On Thursday, September 11, 2003, at 10:02 PM, Greg Stein wrote:
I've written applications like this. One thread will create a mutex,
stash
that away in a global, or somesuch, and then lock the thing *twice*.
When
another thread wants the first one to resume, it unlocks the mutex.
Oh, and FWIW, I
On Thursday, September 11, 2003, at 10:02 PM, Greg Stein wrote:
I've written applications like this. One thread will create a mutex,
stash
that away in a global, or somesuch, and then lock the thing *twice*.
When
another thread wants the first one to resume, it unlocks the mutex.
Eeww, that's no
I propose we do one of the following.
1) Remove nested muxtes, meaning all mutexes become non-nested (they
will
deadlock whenever the same thread locks twice).
Pros: Nested mutexes are lame and are unnecessary. The current
implementation
in APR is broken.
Cons: Some applications m
[X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
[ ] - No, I think we're not ready for 1.0 because __
My belated 2 cents,
-aaron
This looks good to me. Nice catch. +1
(I'm swamped with other things right now, but if someone hasn't
committed this by today or tomorrow I can do it.)
-aaron
On Wednesday, September 3, 2003, at 11:45 AM, Paul Querna wrote:
apr_reslist_create() does not allow the Soft Max or the Hard Max to
equal
I do not believe nested mutexes and condition variables are
compatible.
Do you really need nested mutexes?
-aaron
On Thursday, August 21, 2003, at 02:16 PM, Mark Gooderum wrote:
I've discovered what I think it a bug in the pthreads based
cond_wait() code when used with nested mutexes.
On Thursday, August 7, 2003, at 04:44 PM, William A. Rowe, Jr. wrote:
If this is a serious consideration - perhaps we have a problem with our
implementation.
That's why the atomic stuff is optional. You can chose to make your
binaries incompatible if you so wish.
Note that the actual atomic logi
Won't this introduce a binary dependency on the implementation
of the atomics? What I mean is before, code that used the atomics
was restricted in some cases (solaris) on the same type of underlying
hardware, and could no longer rely on the version of the OS to
determine binary compatibility. Now w
Comments below...
On Wednesday, July 30, 2003, at 09:21 AM, William A. Rowe, Jr. wrote:
Attached is a patch that appears to be as close as thread-safe
(but altogether not reentrant) as I can accomplish.
The existing unix/thread_mutex.c code is neither thread-safe
nor reentrant when using the 'nest
On Tuesday, June 24, 2003, at 11:04 PM, Justin Erenkrantz wrote:
Off the top of my head I would suggest:
* tmpfile handling
* random number generation API
I could conceivably believe that we could push these to post-1.0 if we
had consensus to do so.
These sound like new features to me, not broken
On Tuesday, June 24, 2003, at 08:41 PM, HOR wrote:
There is a possibility of the APR team add a function like
/** Free the given pointer. */
APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
to the current pool system? AFAIK it is only possible to deallocate
memory
deallocat
On Sunday, June 15, 2003, at 11:14 PM, Marc M. Adkins wrote:
Hmmm...does this mean that the APR read/write locks are supposed to
avoid
writer starvation? Should the Windows code be fixed?
I think so, we should try to prevent writer starvation.
-aaron
I think we should just release what we have right now. What would
I need to do to package this up?
-aaron
On Thursday, March 20, 2003, at 08:40 AM, William A. Rowe, Jr. wrote:
I believe this is the final tag. I think the httpd project is still
one day
out of releasing 2.0.45. It seems that apr_
On Wednesday, March 12, 2003, at 11:57 AM, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
striker 2003/03/11 12:02:06
Modified:include apr_pools.h
Log:
* include/apr_pools.h
Add a comment about the order in which cleanups are run. This
has been
the case for quite a while, bu
You just need to get your machine to gather entropy from more sources.
It's not like you create repositories that often, right?
I could see us having a flag to ask for blocking good entropy or
non-blocking not-as-good entropy.
-aaron
On Tuesday, March 11, 2003, at 02:31 PM, Ben Collins-Sussman wro
On Thursday, March 6, 2003, at 12:51 AM, Greg Stein wrote:
Just cut the darned release. If you have time to make a release, then
just
do it. *ANYTHING* that gets released will be better than 0.9.1; we're
a long
ways past that release.
So what if it isn't perfect? That's what another release is
On Thursday, February 27, 2003, at 03:32 PM, Justin Erenkrantz wrote:
--On Thursday, February 27, 2003 23:10:55 +0100 Sander Striker
<[EMAIL PROTECTED]> wrote:
I guess we need to always return APR_EINVAL when a 0 sized mmap is
requested.
Would it be valid to return APR_SUCCESS? Technically, we
It looked fine at first glance, but I'll have to take a
closer look later today.
-aaron
On Tuesday, February 11, 2003, at 10:26 AM, David Reid wrote:
I share the concern so +1 for the concept. I'm also not familiar
enough with
the code to commit it but hopefully someone who is can have a look
be
On Wednesday, January 22, 2003, at 08:57 AM, Justin Erenkrantz wrote:
--On Wednesday, January 22, 2003 5:39 PM +0100 Dirk-Willem van Gulik
<[EMAIL PROTECTED]> wrote:
One 'ultimate' way to proof how much sense it would make is by
using it to do simply/do some clever apache/tomcat connection
pooli
Actually, since bugs like this will be isolated to
development on new parts of APR and can't happen
in application code (these are private headers, afterall),
why don't we just namespace protect them as we come
across them, as in the case of dso.h?
-aaron
On Sunday, January 5, 2003, at 07:45 PM, G
Ouch. Yeah we need namespace protection. +1
-aaron
On Sunday, January 5, 2003, at 03:45 PM, Thom May wrote:
the header files in include/arch/*/* currently have very generic
names, like
"dso.h". I got bit by this earlier when trying to specify the location
of
OpenSSL, which also ships a dso.h
Wou
On Friday, December 20, 2002, at 01:26 PM, <[EMAIL PROTECTED]> wrote:
The pools are used so that we don't
have to track resources this closely, that is, in fact, their main
benefit.
They were also added for performance reasons, but I don't know if
this was a side effect or the main reason. Delayin
On Friday, December 13, 2002, at 09:20 AM, Joe Orton wrote:
For the implementation of name-based apr_shm_create using shmget (i.e.
the filename != NULL case), I've got two questions:
1) why is APR_EXCL passed to the apr_file_open call? This is annoying
for Apache since if the server crashes, you
It looks to me like it's used in conjunction with sendfile
on Linux, and is probably useful for preventing slow starts
on big bursts of data (like a response). I suspect it is
especially useful when each header in the hdtr->headers iovec
is not going to fill a full packet. (Is this thing anything
o
On Sunday, December 8, 2002, at 03:18 PM, Sterling Hughes wrote:
Or perhaps do what the php project does. If you're not a subscriber,
you must perform a one-time "autoresponse," which can reasonably verify
that you are not a spammer.
Any additional spam that is recieved is simply blacklisted. We
[I removed a bunch of people from the cc: list who were obviously
subscribers to this mailing list already]
On Sunday, December 8, 2002, at 02:18 PM, <[EMAIL PROTECTED]> wrote:
Fine, then suggest another method for developers to find a system temp
directory so that they can create a valid mask fo
On Thursday, December 5, 2002, at 01:26 PM, <[EMAIL PROTECTED]> wrote:
On Thu, 5 Dec 2002, Aaron Bannert wrote:
Can anyone think of a case where temp files on Unix do not belong in
either 1) /tmp or 2) a user-defined location?
I know of a couple of Unix platforms that use /var/tmp, yes. Bu
On Thursday, December 5, 2002, at 01:07 PM, <[EMAIL PROTECTED]> wrote:
What exactly is the argument against using the proposed API? That we
shouldn't use environment variables? The environment variables are a
mechanism that some platforms use for locating the temp directory. To
ignore them woul
On Thursday, December 5, 2002, at 12:33 PM, William A. Rowe, Jr. wrote:
Ok... here's how I see us finding common ground...
Add an apr_filepath_temp_set() that allows the developer to override
the temp path for an entire app; e.g. those apps which have a config
directive SetTempPath /zzz can suppor
On Thursday, December 5, 2002, at 10:43 AM, William A. Rowe, Jr. wrote:
As a developer/administrator/user, I *really* get ticked off by those
developers who don't respect my system-wide %TEMP%/%TMP%
assignments. This isn't just a personal choice, since on locked down
boxes or with apps installed
On Thursday, December 5, 2002, at 09:38 AM, [EMAIL PROTECTED] wrote:
Aaron Bannert <[EMAIL PROTECTED]> writes:
I don't like the idea of having environment variables drive things
like this. Temp directories are a great way to get programs to
write files wherever you want. I'd mu
On Wednesday, December 4, 2002, at 10:50 AM, <[EMAIL PROTECTED]> wrote:
On Wed, 4 Dec 2002, David Reid wrote:
I propose that it would simply take the form of a define
#define APR_TMP_DIRECTORY "/var/tmp"
Haven't we discussed this before? I thought we had, and we had
decided to
come up with a hie
On Saturday, November 23, 2002, at 10:39 PM, Justin Erenkrantz wrote:
--On Friday, November 22, 2002 6:51 AM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
Agreed that it is a bug. The question is whether it even makes
sense to use the thread handle or thread ID.
Who is using apr_os_th
On Tuesday, November 19, 2002, at 09:49 PM, <[EMAIL PROTECTED]> wrote:
By allocating the mutex in the pool they have already stated that the
pool
should control the mutex's scope. That is the meaning of allocating a
varibale inside a pool. This is why pools are passed to ALL functions.
BTW, yo
+1, it built fine for me on Darwin.
-aaron
On Tuesday, November 19, 2002, at 04:59 PM, Thom May wrote:
So what is the consensus with the renames? The patch is available from
http://cvs.apache.org/~thommay/full-rename-diff and seems good - it
builds
and passes tests on (at least) BeOS and OS X.
Al
On Tuesday, November 19, 2002, at 01:51 PM, <[EMAIL PROTECTED]> wrote:
apr_proc_mutex_child_init()
Depending on mutex type, the cleanup should be killed or
not. In general, file-based mutex will be killed, but semaphores will
not.
I don't understand this, why does the app trea
On Tuesday, November 19, 2002, at 12:34 PM, <[EMAIL PROTECTED]> wrote:
On 19 Nov 2002, Philip Martin wrote:
<[EMAIL PROTECTED]> writes:
If you don't want the child process to destroy the mutex, then you
should
kill that cleanup in the child process. That is why we have the
apr_pool_cleanup_kill
On Tuesday, November 19, 2002, at 12:02 PM, Philip Martin wrote:
I think the current pool cleanup handler is a mistake. The handler
should cleanup only those resources local to the process, leaving the
proc_mutex in a working state.
This is how it is now, only that when we use fork(), all the cle
On Tuesday, November 19, 2002, at 10:46 AM, <[EMAIL PROTECTED]> wrote:
If you don't want the child process to destroy the mutex, then you
should
kill that cleanup in the child process. That is why we have the
apr_pool_cleanup_kill API.
Naw, we just shouldn't automatically destroy locks in a cle
So are you saying that we should not ever automatically destroy
locks in cleanups?
-aaron
On Tuesday, November 19, 2002, at 08:59 AM, <[EMAIL PROTECTED]> wrote:
This would be a bad design change IMNSHO. The library has no business
deciding when a mutex is destroyed, that is the role of the applic
On Mon, Nov 18, 2002 at 08:20:11PM -0500, Jeff Trawick wrote:
> 2) tweak make_child() in the test program to trap errors from
> apr_proc_mutex_lock() and apr_proc_mutex_unlock()
>
> I bet you are hitting errors with the mutex, but they're not being
> reported right now. And of course if the
On Sun, Nov 17, 2002 at 06:06:20PM -0800, Aaron Bannert wrote:
> On Sat, Nov 16, 2002 at 06:05:05PM -0800, Brian Pane wrote:
> > Intraprocess mutexes have the same problem. Because mutex->owner
> > is of type apr_os_thread_t, there's no guarantee that it's small
>
On Sat, Nov 16, 2002 at 06:05:05PM -0800, Brian Pane wrote:
> Intraprocess mutexes have the same problem. Because mutex->owner
> is of type apr_os_thread_t, there's no guarantee that it's small
> enough to be read or written atomically.
apr_thread_mutex_t will have a problem if mutex->nested can
On Sun, Nov 17, 2002 at 12:25:46PM +, Philip Martin wrote:
> $ ./testprocmutex
> APR Proc Mutex Test
> ==
>
> Exclusive lock test
> Initializing the lock OK
> Starting all of the processes OK
> W
Looks like a bug to me. Any reason we need nested locks on cross-process
mutexes? I'm tempted to just rip out that part and see what breaks.
-aaron
On Sat, Nov 16, 2002 at 11:36:20PM +, Philip Martin wrote:
> Hello
>
> The following issue was raised in the Subversion issue tracker
>
> http
On Tue, Oct 29, 2002 at 12:15:19PM -, [EMAIL PROTECTED] wrote:
> stoddard2002/10/29 04:15:19
>
> Modified:file_io/win32 readwrite.c
> Log:
> Comment a not so obvious tidbit.
>
> Revision ChangesPath
> 1.72 +5 -0 apr/file_io/win32/readwrite.c
>
> Index:
On Tue, Oct 22, 2002 at 09:03:02PM -0500, William A. Rowe, Jr. wrote:
> >Hmm... I haven't looked at the new test stuff, but I wonder how it's
> >going to deal with the testshm* tests, since those tests depend on
> >fork() and exec() to work.
>
> As well as they did before...
>
> ... that is, not
On Tue, Oct 22, 2002 at 11:02:50PM -0400, Ryan Bloom wrote:
> > Hmm... I haven't looked at the new test stuff, but I wonder how it's
> > going to deal with the testshm* tests, since those tests depend on
> > fork() and exec() to work.
>
> Those test will be re-written when I get to them, so that t
On Tue, Oct 22, 2002 at 01:22:08PM -0400, Ryan Bloom wrote:
> ... Previously, each test
> program was it's own binary, and that caused a lot more work than was
> needed. The new test suite is a single program, so just look at
> Makefile.in, at the testall target. If you compile and link every fil
On Tue, Oct 22, 2002 at 01:49:03AM -0400, Ryan Bloom wrote:
> Because there is a difference between unset and NULL value. One of them
> was specifically set by the program, the other is a programmer trying to
> query for a value that was never set. They are two different cases. This
> is the tim
On Tue, Oct 22, 2002 at 01:08:35AM -0400, Ryan Bloom wrote:
> If you try to get a value from the table, and the value isn't set, then we
> shouldn't return NULL. The fact that we can't determine the difference
> between a NULL entry and an unset key is proof that the hash table API is
> incorrect.
On Tue, Oct 22, 2002 at 02:23:20AM -, Ryan Bloom wrote:
> rbb 2002/10/21 19:23:20
>
> Modified:include apr_errno.h
>memory/unix apr_pools.c
> Log:
> Allow people who use userdata to distinguish between a successful retrieval
> from the pool userdata, and no
On Sun, Oct 20, 2002 at 06:39:36PM -0500, William A. Rowe, Jr. wrote:
> >I like the idea, but yeah, to have a global mutex on windows you have
> >to give it a filename (so the non-related processes can rendezvous on
> >the same mutex).
>
> Doesn't it make more sense to use a file lock instead of a
On Sun, Oct 20, 2002 at 11:30:35AM -0400, Jeff Trawick wrote:
> Maybe APR_APPEND needs to be cheap/simple append a la stdio append: we
> seek to the end of the file at open time and forget about it after
> that.
>
> Then we need new APR_WRITE_AT_END or something better named which is
> the expensi
On Mon, Oct 14, 2002 at 10:46:50AM -0400, Ryan Bloom wrote:
> Congratulations Cliff, and the two other candidates. APR is obviously a
> thriving community to have offered up so many strong candidates. :-)
+1, and many thanks to you Ryan for the energy you put in to this
community.
-aaron
On Sun, Oct 13, 2002 at 04:01:45AM -0700, Greg Stein wrote:
> You keep bumping NUM_TESTS and adding entries to the array. You can avoid
> the dual-maintenance and potential for falling out of sync by adding a NULL
> element ("sentinel") to the array to signify the end.
a.k.a. "poison pill".
-aaro
On Sun, Oct 13, 2002 at 11:53:27AM -0400, Ryan Bloom wrote:
> > Is there a more APR-ish way to describe returning "true" or "false"
> > than
>
> As with all other APR functions. APR_SUCCESS indicates "true", Some other
> APR_STATUS code indicates false.
No it doesn't. True and false can be ortho
On Sat, Sep 21, 2002 at 11:32:30AM -0700, Justin Erenkrantz wrote:
> On Sat, Sep 21, 2002 at 02:23:38PM -0400, Jim Jagielski wrote:
> > How would people say would be the best way to port the ShmemUIDisUser
> > code from 1.3 to 2.0/APR... Should I use a simple global var or wrap
> > that in some sor
On Thu, Sep 19, 2002 at 03:33:37PM -0700, Greg Stein wrote:
> On Thu, Sep 19, 2002 at 11:50:04AM -0700, Justin Erenkrantz wrote:
> > On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> > > As I said when apr-config and apu-config were created, it should ONLY
>
On Thu, Sep 19, 2002 at 12:39:30PM -0700, Justin Erenkrantz wrote:
> They have all been converted to use apr-config and apu-config.
I can't remember what the problem was that needed to be solved by doing
this, can you please elaborate? (I'm probably forgetting something..)
> The APR_FIND_APR/APR
On Thu, Sep 19, 2002 at 12:22:57PM -0700, Justin Erenkrantz wrote:
> On Thu, Sep 19, 2002 at 12:13:56PM -0700, Aaron Bannert wrote:
> > Woah there. I'm just talking about apr-config and apu-config. Those
> > scripts are there to help projects find and use and installed versio
On Thu, Sep 19, 2002 at 11:50:04AM -0700, Justin Erenkrantz wrote:
> On Thu, Sep 19, 2002 at 11:09:01AM -0700, Aaron Bannert wrote:
> > As I said when apr-config and apu-config were created, it should ONLY
> > be used from an independently installed APR or APR-UTIL.
>
> For t
1 - 100 of 466 matches
Mail list logo
