Question regarding approach to memory allocation in the APR

[Norman Tuttle <nt...@opendemand.com>]

The conditions of lack of success for apr_socket_create() should include 
a case where memory wasn't available to allocate for the creation of the 
APR socket structure, but I did not see evidence of this in either the 
Win32 or Unix versions of the APR library. Both functions call a void 
function alloc_socket() which does the allocation and then immediately 
sets members of the allocated socket, so they are obviously assuming the 
allocation occurred. Unfortunately, real software cannot be so sure. I 
was wondering if (1) the APR provided alternate functions which check 
for this failure case, and (2) how many APR functions are doing memory 
checking?

-Norman Tuttle, OpenDemand Systems Developer, ntuttle@opendemand.com

Re: [patch] proc_mutex_flock_child_init() should close the file

[Jeff Trawick <tr...@attglobal.net>]

Gregory (Grisha) Trubetskoy wrote:

> In proc_mutex_flock_child_init(), there is no reason to keep the inherited
> file descriptor open, it results in unnecessary open files. Unless I'm
> missing something it's ok to close it first thing in flock_child_init().

sure, definitely a good thing for it not to be open

but maybe in proc_mutex_flock_create() it should be marked as 
uninheritable?  new child processes wouldn't otherwise know to close the 
file unless they ran the flock_child_init code

[patch] proc_mutex_flock_child_init() should close the file

["Gregory (Grisha) Trubetskoy" <gr...@ispol.com>]

In proc_mutex_flock_child_init(), there is no reason to keep the inherited
file descriptor open, it results in unnecessary open files. Unless I'm
missing something it's ok to close it first thing in flock_child_init().
I've tested this on FreeBSD 4.8.

--- locks/unix/proc_mutex.c     6 Aug 2003 23:54:31 -0000       1.35
+++ locks/unix/proc_mutex.c     16 Oct 2003 21:18:48 -0000
@@ -682,6 +682,8 @@
     apr_proc_mutex_t *new_mutex;
     int rv;

+    apr_file_close((*mutex)->interproc);
+
     new_mutex = (apr_proc_mutex_t *)apr_palloc(pool, sizeof(apr_proc_mutex_t));

     memcpy(new_mutex, *mutex, sizeof *new_mutex);

Re: Question regarding approach to memory allocation in the APR

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 04:16 PM 10/16/2003, Norman Tuttle wrote:
>The conditions of lack of success for apr_socket_create() should include a case where memory wasn't available to allocate for the creation of the APR socket structure, but I did not see evidence of this in either the Win32 or Unix versions of the APR library.

Norman, out of memory conditions either cause a segfault (null pointer deref)
or are handled with an absolute, fatal exception from apr_palloc (there is
an overridable callback for that condition.)

The attitude of the Apache HTTP Server project, and the APR project, is that
on an out-of-memory condition it's impossible to ever safely recover.

> Both functions call a void function alloc_socket() which does the allocation and then immediately sets members of the allocated socket, so they are obviously assuming the allocation occurred. Unfortunately, real software cannot be so sure. I was wondering if (1) the APR provided alternate functions which check for this failure case, and (2) how many APR functions are doing memory checking?

The correct ansswer to (2) should be none.