You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by dr...@apache.org on 2001/06/06 20:12:17 UTC
cvs commit: apr/threadproc/unix thread.c
dreid 01/06/06 11:12:17
Modified: . acconfig.h
include apr.h.in apr_lock.h apr_portable.h apr_sms.h
apr_thread_proc.h
include/arch/beos locks.h
include/arch/os2 locks.h
include/arch/unix locks.h
include/arch/win32 locks.h
memory/unix apr_sms_std.c apr_sms_tracking.c
locks/beos crossproc.c locks.c
locks/unix crossproc.c locks.c
locks/win32 locks.c
threadproc/beos thread.c
threadproc/unix thread.c
Log:
This is a much larger commit than I meant to have, but a lot has
been changed in my tree today :)
- remove the sms code I committed yesterday
- add an apr_pool_t to the sms structure
- add locking code to the tracking sms
This threw up an issue with locking, so next
- change the locking code to add an owner and ref counting
so we can lock multiple times from the same thread. this was
needed by the apr_sms_tracking_reset code where we lock
and then call free which locks again...
I haven't added the locking changes for os2 or win32 after
the problems I created with my last commit :)
Changes to testlock on the way.
Revision Changes Path
1.45 +0 -42 apr/acconfig.h
Index: acconfig.h
===================================================================
RCS file: /home/cvs/apr/acconfig.h,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- acconfig.h 2001/06/05 13:21:52 1.44
+++ acconfig.h 2001/06/06 18:10:55 1.45
@@ -67,46 +67,4 @@
#define apr_sigwait(a,b) sigwait((a),(b))
#endif
-/* Macros to deal with using either a pool or an sms
- * to do memory stuff...
- */
-#define APR_CLEANUP_REGISTER(struct, data, func, scope) \
- if (struct->pool) { \
- apr_pool_cleanup_register(struct->pool, data, func, scope); \
- } else { \
- apr_sms_cleanup_register(struct->mem_sys, APR_CHILD_CLEANUP, \
- data, func); \
- }
-
-#define APR_CLEANUP_REMOVE(struct, data, func) \
- if (struct->pool) { \
- apr_pool_cleanup_kill(struct->pool, data, func); \
- } else { \
- apr_sms_cleanup_unregister(struct->mem_sys, APR_CHILD_CLEANUP, \
- data, func); \
- }
-
-#define APR_MEM_PSTRDUP(struct, ptr, str) \
- if (struct->pool) { \
- ptr = apr_pstrdup(struct->pool, str); \
- } else { \
- size_t len = strlen(str) + 1; \
- ptr = (char*) apr_sms_calloc(struct->mem_sys, len); \
- memcpy(ptr, str, len); \
- }
-
-#define APR_MEM_MALLOC(ptr, struct, type) \
- if (struct->pool) { \
- ptr = (type *)apr_palloc(struct->pool, sizeof(type)); \
- } else { \
- ptr = (type *)apr_sms_malloc(struct->mem_sys, sizeof(type)); \
- }
-
-#define APR_MEM_CALLOC(ptr, struct, type) \
- if (struct->pool) { \
- ptr = (type *)apr_pcalloc(struct->pool, sizeof(type)); \
- } else { \
- ptr = (type *)apr_sms_calloc(struct->mem_sys, sizeof(type)); \
- }
-
#endif /* APR_PRIVATE_H */
1.82 +0 -3 apr/include/apr.h.in
Index: apr.h.in
===================================================================
RCS file: /home/cvs/apr/include/apr.h.in,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- apr.h.in 2001/06/05 08:15:05 1.81
+++ apr.h.in 2001/06/06 18:11:01 1.82
@@ -174,9 +174,6 @@
typedef @off_t_value@ apr_off_t;
typedef @socklen_t_value@ apr_socklen_t;
-typedef struct apr_lock_t apr_lock_t;
-typedef struct apr_sms_t apr_sms_t;
-
/* Mechanisms to properly type numeric literals */
@int64_literal@
1.27 +2 -1 apr/include/apr_lock.h
Index: apr_lock.h
===================================================================
RCS file: /home/cvs/apr/include/apr_lock.h,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- apr_lock.h 2001/06/05 13:21:59 1.26
+++ apr_lock.h 2001/06/06 18:11:02 1.27
@@ -58,7 +58,6 @@
#include "apr.h"
#include "apr_pools.h"
#include "apr_errno.h"
-#include "apr_sms.h"
#ifdef __cplusplus
extern "C" {
@@ -73,6 +72,8 @@
typedef enum {APR_MUTEX, APR_READWRITE} apr_locktype_e;
typedef enum {APR_READER, APR_WRITER} apr_readerwriter_e;
+
+typedef struct apr_lock_t apr_lock_t;
/* Function definitions */
1.55 +2 -0 apr/include/apr_portable.h
Index: apr_portable.h
===================================================================
RCS file: /home/cvs/apr/include/apr_portable.h,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- apr_portable.h 2001/05/23 12:27:29 1.54
+++ apr_portable.h 2001/06/06 18:11:04 1.55
@@ -418,6 +418,8 @@
APR_DECLARE(apr_status_t) apr_os_dso_handle_get(apr_os_dso_handle_t *dso,
apr_dso_handle_t *aprdso);
+APR_DECLARE(apr_os_thread_t) apr_os_thread_current(void);
+
#endif /* APR_HAS_DSO */
#ifdef __cplusplus
1.11 +25 -20 apr/include/apr_sms.h
Index: apr_sms.h
===================================================================
RCS file: /home/cvs/apr/include/apr_sms.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- apr_sms.h 2001/06/05 09:23:30 1.10
+++ apr_sms.h 2001/06/06 18:11:05 1.11
@@ -65,6 +65,8 @@
#include "apr.h"
#include "apr_errno.h"
+#include "apr_pools.h"
+#include "apr_lock.h"
#ifdef __cplusplus
extern "C" {
@@ -80,32 +82,35 @@
*/
struct apr_sms_cleanup;
+typedef struct apr_sms_t apr_sms_t;
/**
* The memory system structure
*/
struct apr_sms_t
{
- apr_sms_t *parent_mem_sys;
- apr_sms_t *child_mem_sys;
- apr_sms_t *sibling_mem_sys;
- apr_sms_t **ref_mem_sys;
- apr_sms_t *accounting_mem_sys;
- const char *identity; /* a string identifying the module */
- apr_lock_t *lock;
-
- struct apr_sms_cleanup *cleanups;
-
- void * (*malloc_fn) (apr_sms_t *mem_sys, apr_size_t size);
- void * (*calloc_fn) (apr_sms_t *mem_sys, apr_size_t size);
- void * (*realloc_fn) (apr_sms_t *mem_sys, void *memory,
- apr_size_t size);
- apr_status_t (*free_fn) (apr_sms_t *mem_sys, void *memory);
- apr_status_t (*reset_fn) (apr_sms_t *mem_sys);
- void (*pre_destroy_fn) (apr_sms_t *mem_sys);
- apr_status_t (*destroy_fn)(apr_sms_t *mem_sys);
- apr_status_t (*lock_fn) (apr_sms_t *mem_sys);
- apr_status_t (*unlock_fn) (apr_sms_t *mem_sys);
+ apr_sms_t *parent_mem_sys;
+ apr_sms_t *child_mem_sys;
+ apr_sms_t *sibling_mem_sys;
+ apr_sms_t **ref_mem_sys;
+ apr_sms_t *accounting_mem_sys;
+ const char *identity; /* a string identifying the module */
+
+ apr_pool_t *pool;
+ apr_lock_t *lock;
+
+ struct apr_sms_cleanup *cleanups;
+
+ void * (*malloc_fn) (apr_sms_t *mem_sys, apr_size_t size);
+ void * (*calloc_fn) (apr_sms_t *mem_sys, apr_size_t size);
+ void * (*realloc_fn) (apr_sms_t *mem_sys, void *memory,
+ apr_size_t size);
+ apr_status_t (*free_fn) (apr_sms_t *mem_sys, void *memory);
+ apr_status_t (*reset_fn) (apr_sms_t *mem_sys);
+ void (*pre_destroy_fn) (apr_sms_t *mem_sys);
+ apr_status_t (*destroy_fn)(apr_sms_t *mem_sys);
+ apr_status_t (*lock_fn) (apr_sms_t *mem_sys);
+ apr_status_t (*unlock_fn) (apr_sms_t *mem_sys);
};
/*
1.65 +1 -0 apr/include/apr_thread_proc.h
Index: apr_thread_proc.h
===================================================================
RCS file: /home/cvs/apr/include/apr_thread_proc.h,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- apr_thread_proc.h 2001/05/16 20:55:49 1.64
+++ apr_thread_proc.h 2001/06/06 18:11:06 1.65
@@ -65,6 +65,7 @@
#include <sys/resource.h>
#endif
+
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
1.15 +2 -6 apr/include/arch/beos/locks.h
Index: locks.h
===================================================================
RCS file: /home/cvs/apr/include/arch/beos/locks.h,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- locks.h 2001/06/05 13:22:06 1.14
+++ locks.h 2001/06/06 18:11:16 1.15
@@ -60,13 +60,13 @@
#include "apr_file_io.h"
#include "apr_general.h"
#include "apr_lib.h"
-#include "apr_sms.h"
struct apr_lock_t {
apr_pool_t *pool;
- apr_sms_t *mem_sys;
apr_locktype_e type;
apr_lockscope_e scope;
+ apr_os_thread_t *owner;
+ int owner_ref;
/* Inter proc */
sem_id sem_interproc;
int32 ben_interproc;
@@ -87,10 +87,6 @@
apr_status_t child_init_lock(struct apr_lock_t **lock, apr_pool_t *cont,
const char *fname);
-
-apr_status_t apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys);
#endif /* LOCKS_H */
1.14 +0 -6 apr/include/arch/os2/locks.h
Index: locks.h
===================================================================
RCS file: /home/cvs/apr/include/arch/os2/locks.h,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- locks.h 2001/06/05 13:22:12 1.13
+++ locks.h 2001/06/06 18:11:22 1.14
@@ -57,11 +57,9 @@
#include "apr_lock.h"
#include "apr_file_io.h"
-#include "apr_sms.h"
struct apr_lock_t {
apr_pool_t *pool;
- apr_sms_t *mem_sys;
apr_locktype_e type;
apr_lockscope_e scope;
char *fname;
@@ -70,10 +68,6 @@
int lock_count;
TIB *tib;
};
-
-apr_status_t apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys);
#endif /* LOCKS_H */
1.30 +6 -5 apr/include/arch/unix/locks.h
Index: locks.h
===================================================================
RCS file: /home/cvs/apr/include/arch/unix/locks.h,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- locks.h 2001/06/05 13:22:18 1.29
+++ locks.h 2001/06/06 18:11:28 1.30
@@ -61,6 +61,7 @@
#include "apr_lib.h"
#include "apr_lock.h"
#include "apr_sms.h"
+#include "apr_portable.h"
/* System headers required by Locks library */
#if APR_HAVE_SYS_TYPES_H
@@ -110,11 +111,11 @@
struct apr_lock_t {
apr_pool_t *pool;
- apr_sms_t *mem_sys;
apr_locktype_e type;
apr_lockscope_e scope;
int curr_locked;
char *fname;
+
#if APR_USE_SYSVSEM_SERIALIZE
int interproc;
#elif APR_USE_FCNTL_SERIALIZE
@@ -129,6 +130,10 @@
#if APR_HAS_THREADS
/* APR doesn't have threads, no sense in having an thread lock mechanism.
*/
+
+ apr_os_thread_t owner;
+ int owner_ref;
+
#if APR_USE_PTHREAD_SERIALIZE
pthread_mutex_t *intraproc;
#endif
@@ -156,10 +161,6 @@
apr_status_t apr_unix_child_init_lock(struct apr_lock_t **lock,
apr_pool_t *cont, const char *fname);
-
-apr_status_t apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys);
#endif /* LOCKS_H */
1.12 +0 -6 apr/include/arch/win32/locks.h
Index: locks.h
===================================================================
RCS file: /home/cvs/apr/include/arch/win32/locks.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- locks.h 2001/06/06 00:07:46 1.11
+++ locks.h 2001/06/06 18:11:34 1.12
@@ -56,21 +56,15 @@
#define LOCKS_H
#include "apr_lock.h"
-#include "apr_sms.h"
struct apr_lock_t {
apr_pool_t *pool;
- apr_sms_t *mem_sys;
apr_locktype_e type;
apr_lockscope_e scope;
HANDLE mutex;
CRITICAL_SECTION section;
char *fname;
};
-
-APR_DECLARE(apr_status_t) apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys);
#endif /* LOCKS_H */
1.7 +3 -0 apr/memory/unix/apr_sms_std.c
Index: apr_sms_std.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_sms_std.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- apr_sms_std.c 2001/06/04 23:09:34 1.6
+++ apr_sms_std.c 2001/06/06 18:11:39 1.7
@@ -127,6 +127,9 @@
new_mem_sys->free_fn = apr_sms_std_free;
new_mem_sys->identity = module_identity;
+ /* If this fails, what should we do??? */
+ apr_pool_create(&(new_mem_sys->pool), NULL);
+
/* as we're not a tracking memory module, i.e. we don't keep
* track of our allocations, we don't have apr_sms_reset or
* apr_sms_destroy functions.
1.7 +43 -3 apr/memory/unix/apr_sms_tracking.c
Index: apr_sms_tracking.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_sms_tracking.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- apr_sms_tracking.c 2001/06/04 23:09:34 1.6
+++ apr_sms_tracking.c 2001/06/06 18:11:41 1.7
@@ -86,11 +86,23 @@
apr_track_node_t *nodes;
} apr_sms_tracking_t;
+static apr_status_t apr_sms_tracking_lock(apr_sms_t *mem_sys)
+{
+ return apr_lock_acquire(mem_sys->lock);
+}
+
+static apr_status_t apr_sms_tracking_unlock(apr_sms_t *mem_sys)
+{
+ return apr_lock_release(mem_sys->lock);
+}
+
static void *apr_sms_tracking_malloc(apr_sms_t *mem_sys,
apr_size_t size)
{
apr_sms_tracking_t *tms;
apr_track_node_t *node;
+
+ apr_sms_tracking_lock(mem_sys);
tms = (apr_sms_tracking_t *)mem_sys;
node = apr_sms_malloc(mem_sys->parent_mem_sys,
@@ -106,6 +118,8 @@
node++;
+ apr_sms_tracking_unlock(mem_sys);
+
return (void *)node;
}
@@ -115,6 +129,8 @@
apr_sms_tracking_t *tms;
apr_track_node_t *node;
+ apr_sms_tracking_lock(mem_sys);
+
tms = (apr_sms_tracking_t *)mem_sys;
node = apr_sms_calloc(mem_sys->parent_mem_sys,
size + sizeof(apr_track_node_t));
@@ -129,6 +145,8 @@
node++;
+ apr_sms_tracking_unlock(mem_sys);
+
return (void *)node;
}
@@ -138,6 +156,8 @@
apr_sms_tracking_t *tms;
apr_track_node_t *node;
+ apr_sms_tracking_lock(mem_sys);
+
tms = (apr_sms_tracking_t *)mem_sys;
node = (apr_track_node_t *)mem;
@@ -159,6 +179,8 @@
node++;
+ apr_sms_tracking_unlock(mem_sys);
+
return (void *)node;
}
@@ -166,14 +188,18 @@
void *mem)
{
apr_track_node_t *node;
-
+
+ apr_sms_tracking_lock(mem_sys);
+
node = (apr_track_node_t *)mem;
node--;
*(node->ref) = node->next;
if (node->next)
node->next->ref = node->ref;
-
+
+ apr_sms_tracking_unlock(mem_sys);
+
return apr_sms_free(mem_sys->parent_mem_sys, node);
}
@@ -182,6 +208,9 @@
apr_sms_tracking_t *tms;
apr_track_node_t *node;
apr_status_t rv;
+
+ if ((rv = apr_sms_tracking_lock(mem_sys)) != APR_SUCCESS)
+ return rv;
tms = (apr_sms_tracking_t *)mem_sys;
@@ -191,10 +220,15 @@
if (node->next)
node->next->ref = node->ref;
if ((rv = apr_sms_free(mem_sys->parent_mem_sys,
- node)) != APR_SUCCESS)
+ node)) != APR_SUCCESS) {
+ apr_sms_tracking_unlock(mem_sys);
return rv;
+ }
}
+ if ((rv = apr_sms_tracking_unlock(mem_sys)) != APR_SUCCESS)
+ return rv;
+
return APR_SUCCESS;
}
@@ -233,8 +267,14 @@
new_mem_sys->realloc_fn = apr_sms_tracking_realloc;
new_mem_sys->free_fn = apr_sms_tracking_free;
new_mem_sys->reset_fn = apr_sms_tracking_reset;
+ new_mem_sys->lock_fn = apr_sms_tracking_lock;
+ new_mem_sys->unlock_fn = apr_sms_tracking_unlock;
new_mem_sys->destroy_fn = apr_sms_tracking_destroy;
new_mem_sys->identity = module_identity;
+
+ apr_pool_create(&(new_mem_sys->pool), pms->pool);
+ apr_lock_create(&(new_mem_sys->lock), APR_MUTEX, APR_LOCKALL, NULL,
+ new_mem_sys->pool);
tms = (apr_sms_tracking_t *)new_mem_sys;
tms->nodes = NULL;
1.23 +3 -3 apr/locks/beos/crossproc.c
Index: crossproc.c
===================================================================
RCS file: /home/cvs/apr/locks/beos/crossproc.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- crossproc.c 2001/06/05 13:22:27 1.22
+++ crossproc.c 2001/06/06 18:11:46 1.23
@@ -82,8 +82,8 @@
}
new->ben_interproc = 0;
new->sem_interproc = stat;
- APR_CLEANUP_REGISTER(new, (void *)new, lock_inter_cleanup,
- apr_pool_cleanup_null);
+ apr_pool_cleanup_register(new->pool, (void *)new, lock_inter_cleanup,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}
@@ -117,7 +117,7 @@
{
apr_status_t stat;
if ((stat = lock_inter_cleanup(lock)) == APR_SUCCESS) {
- APR_CLEANUP_REMOVE(lock, lock, lock_inter_cleanup);
+ apr_pool_cleanup_kill(lock->pool, lock, lock_inter_cleanup);
return APR_SUCCESS;
}
return stat;
1.30 +17 -34 apr/locks/beos/locks.c
Index: locks.c
===================================================================
RCS file: /home/cvs/apr/locks/beos/locks.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- locks.c 2001/06/05 13:22:30 1.29
+++ locks.c 2001/06/06 18:11:48 1.30
@@ -90,44 +90,15 @@
return APR_SUCCESS;
}
-apr_status_t apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys)
-{
- apr_lock_t *new;
- apr_status_t stat;
-
- /* FIXME: Remove when read write locks implemented. */
- if (type == APR_READWRITE)
- return APR_ENOTIMPL;
-
- new = (apr_lock_t *)apr_sms_calloc(mem_sys, sizeof(apr_lock_t));
- if (new == NULL){
- return APR_ENOMEM;
- }
-
- new->mem_sys = mem_sys;
- new->type = type;
- new->scope = scope;
-
- if (scope != APR_CROSS_PROCESS) {
- if ((stat = create_intra_lock(new)) != APR_SUCCESS) {
- return stat;
- }
- }
- if (scope != APR_INTRAPROCESS) {
- if ((stat = create_inter_lock(new)) != APR_SUCCESS) {
- return stat;
- }
- }
- (*lock) = new;
- return APR_SUCCESS;
-}
-
apr_status_t apr_lock_acquire(apr_lock_t *lock)
{
apr_status_t stat;
+ if (lock->owner == apr_os_thread_current()) {
+ lock->owner_ref++;
+ return APR_SUCCESS;
+ }
+
switch (lock->type)
{
case APR_MUTEX:
@@ -146,6 +117,9 @@
return APR_ENOTIMPL;
}
+ lock->owner = apr_os_thread_current();
+ lock->owner_ref = 1;
+
return APR_SUCCESS;
}
@@ -173,6 +147,12 @@
{
apr_status_t stat;
+ if (lock->owner == apr_os_thread_current()) {
+ lock->owner_ref--;
+ if (lock->owner_ref > 0)
+ return APR_SUCCESS;
+ }
+
switch (lock->type)
{
case APR_MUTEX:
@@ -190,6 +170,9 @@
case APR_READWRITE:
return APR_ENOTIMPL;
}
+
+ lock->owner = -1;
+ lock->owner_ref = 0;
return APR_SUCCESS;
}
1.45 +14 -10 apr/locks/unix/crossproc.c
Index: crossproc.c
===================================================================
RCS file: /home/cvs/apr/locks/unix/crossproc.c,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- crossproc.c 2001/06/05 13:22:42 1.44
+++ crossproc.c 2001/06/06 18:11:55 1.45
@@ -100,7 +100,8 @@
return errno;
}
new->curr_locked = 0;
- APR_CLEANUP_REGISTER(new, (void *)new, lock_cleanup, apr_pool_cleanup_null);
+ apr_pool_cleanup_register(new->pool, (void *)new, lock_cleanup,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}
@@ -137,7 +138,7 @@
apr_status_t stat;
if ((stat = lock_cleanup(lock)) == APR_SUCCESS) {
- APR_CLEANUP_REMOVE(lock, lock, lock_cleanup);
+ apr_pool_cleanup_kill(lock->pool, lock, lock_cleanup);
return APR_SUCCESS;
}
return stat;
@@ -223,7 +224,8 @@
}
new->curr_locked = 0;
- APR_CLEANUP_REGISTER(new, (void *)new, lock_cleanup, apr_pool_cleanup_null);
+ apr_pool_register_cleanup(new->pool, (void *)new, lock_cleanup,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}
@@ -259,7 +261,7 @@
{
apr_status_t stat;
if ((stat = lock_cleanup(lock)) == APR_SUCCESS) {
- APR_CLEANUP_REMOVE(lock, lock, lock_cleanup);
+ apr_pool_cleanup_kill(lock->pool, lock, lock_cleanup);
return APR_SUCCESS;
}
return stat;
@@ -305,7 +307,7 @@
new->interproc = open(new->fname, O_CREAT | O_WRONLY | O_EXCL, 0644);
}
else {
- APR_MEM_PSTRDUP(new, new->fname, "/tmp/aprXXXXXX")
+ new->fname = apr_pstrdup(new->pool, "/tmp/aprXXXXXX");
new->interproc = apr_mkstemp(new->fname);
}
@@ -316,7 +318,8 @@
new->curr_locked=0;
unlink(new->fname);
- APR_CLEANUP_REGISTER(new, new, lock_cleanup, apr_pool_cleanup_null);
+ apr_pool_cleanup_register(new->pool, (void*)new, lock_cleanup,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}
@@ -352,7 +355,7 @@
{
apr_status_t stat;
if ((stat = lock_cleanup(lock)) == APR_SUCCESS) {
- APR_CLEANUP_REMOVE(lock, lock, lock_cleanup);
+ apr_pool_cleanup_kill(lock->pool, lock, lock_cleanup);
return APR_SUCCESS;
}
return stat;
@@ -388,7 +391,7 @@
new->interproc = open(new->fname, O_CREAT | O_WRONLY | O_EXCL, 0600);
}
else {
- APR_MEM_PSTRDUP(new, new->fname, "/tmp/aprXXXXXX")
+ new->fname = apr_pstrdup(new->pool, "/tmp/aprXXXXXX");
new->interproc = apr_mkstemp(new->fname);
}
@@ -397,7 +400,8 @@
return errno;
}
new->curr_locked = 0;
- APR_CLEANUP_REGISTER(new, (void *)new, lock_cleanup, apr_pool_cleanup_null);
+ apr_pool_cleanup_register(new->pool, (void *)new, lock_cleanup,
+ apr_pool_cleanup_null);
return APR_SUCCESS;
}
@@ -433,7 +437,7 @@
{
apr_status_t stat;
if ((stat = lock_cleanup(lock)) == APR_SUCCESS) {
- APR_CLEANUP_REMOVE(lock, lock, lock_cleanup);
+ apr_pool_cleanup_kill(lock->new, lock, lock_cleanup);
return APR_SUCCESS;
}
return stat;
1.51 +26 -21 apr/locks/unix/locks.c
Index: locks.c
===================================================================
RCS file: /home/cvs/apr/locks/unix/locks.c,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- locks.c 2001/06/05 13:48:25 1.50
+++ locks.c 2001/06/06 18:11:59 1.51
@@ -67,7 +67,7 @@
/* file-based serialization primitives */
if (new->scope != APR_INTRAPROCESS) {
if (fname != NULL) {
- APR_MEM_PSTRDUP(new, new->fname, fname);
+ new->fname = apr_pstrdup(new->pool, fname);
}
}
#endif
@@ -126,30 +126,17 @@
return APR_SUCCESS;
}
-apr_status_t apr_lock_sms_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_sms_t *mem_sys)
-{
- apr_lock_t *new;
- apr_status_t stat;
-
- new = (apr_lock_t *)apr_sms_calloc(mem_sys, sizeof(apr_lock_t));
-
- new->mem_sys = mem_sys;
- new->type = type;
- new->scope = scope;
-
- if ((stat = create_lock(new, fname)) != APR_SUCCESS)
- return stat;
-
- *lock = new;
- return APR_SUCCESS;
-}
-
apr_status_t apr_lock_acquire(apr_lock_t *lock)
{
apr_status_t stat;
+#if APR_HAS_THREADS
+ if (lock->owner == apr_os_thread_current()){
+ lock->owner_ref++;
+ return APR_SUCCESS;
+ }
+#endif
+
switch (lock->type)
{
case APR_MUTEX:
@@ -176,6 +163,11 @@
return APR_ENOTIMPL;
}
+#if APR_HAS_THREADS
+ lock->owner = apr_os_thread_current();
+ lock->owner_ref = 1;
+#endif
+
return APR_SUCCESS;
}
@@ -211,6 +203,14 @@
{
apr_status_t stat;
+#if APR_HAS_THREADS
+ if (lock->owner == apr_os_thread_current()) {
+ lock->owner_ref--;
+ if (lock->owner_ref > 0)
+ return APR_SUCCESS;
+ }
+#endif
+
switch (lock->type)
{
case APR_MUTEX:
@@ -242,6 +242,11 @@
return APR_ENOTIMPL;
#endif
}
+
+#if APR_HAS_THREADS
+ lock->owner = NULL;
+ lock->owner_ref = 0;
+#endif
return APR_SUCCESS;
}
1.43 +0 -39 apr/locks/win32/locks.c
Index: locks.c
===================================================================
RCS file: /home/cvs/apr/locks/win32/locks.c,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- locks.c 2001/06/06 03:57:47 1.42
+++ locks.c 2001/06/06 18:12:04 1.43
@@ -100,45 +100,6 @@
return APR_SUCCESS;
}
-APR_DECLARE(apr_status_t) apr_lock_sms_create(apr_lock_t **lock,
- apr_locktype_e type,
- apr_lockscope_e scope,
- const char *fname,
- apr_sms_t *mem_sys)
-{
- apr_lock_t *newlock;
- SECURITY_ATTRIBUTES sec;
-
- if (type == APR_READWRITE)
- return APR_ENOTIMPL;
-
- newlock = (apr_lock_t *)apr_sms_malloc(mem_sys, sizeof(apr_lock_t));
-
- newlock->pool = NULL;
- newlock->mem_sys = mem_sys;
-
- APR_MEM_PSTRDUP(newlock, newlock->fname, fname);
- newlock->type = type;
- newlock->scope = scope;
- sec.nLength = sizeof(SECURITY_ATTRIBUTES);
- sec.lpSecurityDescriptor = NULL;
-
- if (scope == APR_CROSS_PROCESS || scope == APR_LOCKALL) {
- sec.bInheritHandle = TRUE;
- }
- else {
- sec.bInheritHandle = FALSE;
- }
-
- if (scope == APR_INTRAPROCESS) {
- InitializeCriticalSection(&newlock->section);
- } else {
- newlock->mutex = CreateMutex(&sec, FALSE, fname);
- }
- *lock = newlock;
- return APR_SUCCESS;
-}
-
APR_DECLARE(apr_status_t) apr_lock_child_init(apr_lock_t **lock,
const char *fname,
apr_pool_t *pool)
1.21 +6 -0 apr/threadproc/beos/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/beos/thread.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- thread.c 2001/04/11 02:01:19 1.20
+++ thread.c 2001/06/06 18:12:08 1.21
@@ -53,6 +53,7 @@
*/
#include "threadproc.h"
+#include "apr_portable.h"
apr_status_t apr_threadattr_create(apr_threadattr_t **new, apr_pool_t *cont)
{
@@ -120,6 +121,11 @@
else {
return errno;
}
+}
+
+apr_os_thread_t apr_os_thread_current(void)
+{
+ return find_thread(NULL);
}
apr_status_t apr_thread_exit(apr_thread_t *thd, apr_status_t *retval)
1.38 +5 -0 apr/threadproc/unix/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/unix/thread.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- thread.c 2001/04/11 02:01:22 1.37
+++ thread.c 2001/06/06 18:12:14 1.38
@@ -158,6 +158,11 @@
}
}
+apr_os_thread_t apr_os_thread_current(void)
+{
+ return pthread_self();
+}
+
apr_status_t apr_thread_exit(apr_thread_t *thd, apr_status_t *retval)
{
apr_pool_destroy(thd->cntxt);
Re: cvs commit: apr/threadproc/unix thread.c
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: <dr...@apache.org>
Sent: Wednesday, June 06, 2001 1:12 PM
> This threw up an issue with locking, so next
>
> - change the locking code to add an owner and ref counting
> so we can lock multiple times from the same thread. this was
> needed by the apr_sms_tracking_reset code where we lock
> and then call free which locks again...
>
> I haven't added the locking changes for os2 or win32 after
> the problems I created with my last commit :)
David [and anyone] - you are welcome to insert the appropriate code in os2 or win32,
whenever you need. It makes it a bit more apparent what you are trying to accomplish,
and a few /* XXX:Need to ... */ comments help enormously.
Bill
Re: cvs commit: apr/threadproc/unix thread.c
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: <dr...@apache.org>
Sent: Wednesday, June 06, 2001 1:12 PM
> This threw up an issue with locking, so next
>
> - change the locking code to add an owner and ref counting
> so we can lock multiple times from the same thread. this was
> needed by the apr_sms_tracking_reset code where we lock
> and then call free which locks again...
>
> I haven't added the locking changes for os2 or win32 after
> the problems I created with my last commit :)
David [and anyone] - you are welcome to insert the appropriate code in os2 or win32,
whenever you need. It makes it a bit more apparent what you are trying to accomplish,
and a few /* XXX:Need to ... */ comments help enormously.
Bill
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> That implies that somebody has to alloc a lock outside, but we know that we
> can do that: an SMS around malloc(), a pool around that, then a lock using
> that pool. We can then pass that lock to SMS(my-custom-bugger).
this lock would be passed in as an argument to the initialisation /
creation of an SMS instance, yes?
oh, and btw, i'm glad to see that someone else gets this sms
stuff :)
luke
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 06, 2001 at 03:02:44PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
>
> > On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> > > - add an apr_pool_t to the sms structure
> >
> > -1 (non-veto, but awfully close). Uh, why are we doing this?
> > I thought that a pool would be defined in terms of a sms (not now, but
> > at some point). This would not allow that to happen.
> > I'm still not entirely sold on the fact that sms needs locks. I think
> > the locks can be handled at a higher level than sms (i.e. a pool).
>
> I was thinking the exact same thing, actually...
Me three.
I thought SMS was to be the underlying memory abstraction, and pools would
be implemented on *top* of those.
I'm not with Justin on the locking, though: I can see that an SMS would need
to use locks to protect itself. But I would recommend that we pass in an
apr_lock_t *if* an SMS should bother with locking. i.e. pass NULL if the SMS
won't need to worry about it (it will only be used from a single thread)
That implies that somebody has to alloc a lock outside, but we know that we
can do that: an SMS around malloc(), a pool around that, then a lock using
that pool. We can then pass that lock to SMS(my-custom-bugger).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > As for locking, well the logical level for locking to be implemented is in
> > the sms module. Look at the standard module. malloc should be thread safe
> > so no locking should be required, hence we don't have any. In a tracking
> > system we can't guarantee that so we lock.
>
> I don't really have a problem with the locking end of things, per se...
> there will probably be some SMS's that need to lock, so we might as well
> give them a convenient means to do so. I think. I haven't really looked
> into this, though.
i've been investigating the design: a lock global and lock region (and
unlocking equivs) will be needed, even if the sms implementor
decides to implement the lock region as a global lock with ref-counting
or something stupid.
luke
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jun 07, 2001 at 08:03:46AM -0700, rbb@covalent.net wrote:
>
> As it happens, this is exactly what I envisioned when SMS was first
> discussed. Namely, a new back-end for pools that can use any allocator.
ack. sorry for thinking otherwise.
luke
Re: cvs commit: apr/threadproc/unix thread.c
Posted by rb...@covalent.net.
As it happens, this is exactly what I envisioned when SMS was first
discussed. Namely, a new back-end for pools that can use any allocator.
Ryan
On Thu, 7 Jun 2001, Luke Kenneth Casson Leighton wrote:
> > > See, that's where my overall view of "where we hope to get to" differs.
> > > <shrug> In my mind, APR depends on pools. Period. It would require a
> > > major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> > > of apr_sms_free operations would have to be added, which is exactly what
> > > the pools are meant to avoid).
>
> no, no, _wrong_! that's exactly what you _don't_ do, and anyone
> who proposes it, or thinks that that is what is being proposed, i
> will stamp on their fingers or break their keyboard in frustration.
>
> or something.
>
> no. we are _not_ proposing that pools be replaced [with something
> other than what looks exactly like pools].
>
> same API [pools], different implementation.
>
> doing otherwise is just.. _nuts_!
>
> you know that, _i_ know that. what on earth makes you think _i_ think
> otherwise???
>
> darn :)
>
> luke
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > See, that's where my overall view of "where we hope to get to" differs.
> > <shrug> In my mind, APR depends on pools. Period. It would require a
> > major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> > of apr_sms_free operations would have to be added, which is exactly what
> > the pools are meant to avoid).
no, no, _wrong_! that's exactly what you _don't_ do, and anyone
who proposes it, or thinks that that is what is being proposed, i
will stamp on their fingers or break their keyboard in frustration.
or something.
no. we are _not_ proposing that pools be replaced [with something
other than what looks exactly like pools].
same API [pools], different implementation.
doing otherwise is just.. _nuts_!
you know that, _i_ know that. what on earth makes you think _i_ think
otherwise???
darn :)
luke
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 6 Jun 2001, Cliff Woolley wrote:
> newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
> because then you have to be sure to
>
> apr_sms_free(str)
Make that apr_sms_free(newstr). ;-)
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 06, 2001 at 08:02:06PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> > I think the thing is that I've seen the sms as slightly different than
> > what it was originally posted as. So, I might be in the minority
> > here. I think we are seeing two different views of what an sms should
> > be.
> >
> > My -1 was non-veto, so it doesn't stop you. It just registers my
> > dissent. -- justin
>
> The group has told me before that, since all code matters require a
> consensus, -1 always means veto. If you really, really, really don't like
> it but don't want to veto it, use -0.5 or -0.99 or something. =-) Only
> in non-consensus-requiring matters do -1's count as "negative votes", but
> those matters seem to only exist in administrative matters, not code
> matters.
Exactly.
-1 is a veto when it comes to code. And as a committer [Justin], you have
veto rights.
Non-committers can vote however they'd like. It is even encouraged. Their
votes are non-binding, but it can help the committers decide on a plan of
action.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> Ah. Okay. I thought I've seen people say "-1 (non-veto)" before. Fine,
You have. We're inconsistent as usual. =-) Just thought I'd mention it
since it's been mentioned to me in a very similar situation.
> consider my vote -0.99999 (because I'm that close to vetoing it, but
> I'm not going to do that). Hopefully, my intention *not* to veto
> is and was clear.
It was.
> My apologies.
No sweat. =-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jun 06, 2001 at 08:02:06PM -0400, Cliff Woolley wrote:
> The group has told me before that, since all code matters require a
> consensus, -1 always means veto. If you really, really, really don't like
> it but don't want to veto it, use -0.5 or -0.99 or something. =-) Only
> in non-consensus-requiring matters do -1's count as "negative votes", but
> those matters seem to only exist in administrative matters, not code
> matters.
Ah. Okay. I thought I've seen people say "-1 (non-veto)" before. Fine,
consider my vote -0.99999 (because I'm that close to vetoing it, but
I'm not going to do that). Hopefully, my intention *not* to veto
is and was clear. My apologies.
FWIW, I'm emailing Dave privately to see if we aren't that far off
on what we want re: sms and pools... -- justin
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jun 07, 2001 at 09:27:00AM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 03:54:24PM +0200, Luke Kenneth Casson Leighton wrote:
> > only an SMS instance should know exactly how to deal with its
> > memory - _including_ locking - IF it is needed.
>
> Ah. I see the logic in that. Thanks for explaining. =)
np.
> Yes, the SMS should be the only one dealing with locking. I'm sold on
> that now.
cool. *happy*.
> Late for class now. -- justin
eek! :)
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jun 07, 2001 at 03:54:24PM +0200, Luke Kenneth Casson Leighton wrote:
> only an SMS instance should know exactly how to deal with its
> memory - _including_ locking - IF it is needed.
Ah. I see the logic in that. Thanks for explaining. =)
Yes, the SMS should be the only one dealing with locking. I'm sold on
that now.
Late for class now. -- justin
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jun 06, 2001 at 04:34:22PM -0700, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks. We don't yet have a module that
> > would allow us to even get close to replacing pools. We need a lot of
> > things from it and Sander and I have had some good early discussions about
> > how it could work. Basically we want to have a fast, stable tracking
> > allocator that has a smaller memory footprint than pools. Is it possible?
> > I don't honestly know but we're going to give it a good try. Why haven't we
> > opened up our discussions? Because we haven't even got any code and are
> > still bashing around the early design which is probably better done
> > privately. Once we have something we like we'll post.
>
> See, I think this is the difference. I see that the pools are on top of
> sms. (Gee, this is what Cliff said...) The sms doesn't need to know
> anything about refcounting or anything special. What does refcounting
> give you? I'm still not also sure why locking needs to be in the SMS.
because, by handing over responsibility for locking of memory to
SMS, and by having the pools code use SMS, you make the pools code
a) simpler b) more powerful.
only an SMS instance should know exactly how to deal with its
memory - _including_ locking - IF it is needed.
as people have already pointed out.
if you want the same thing _without_ using SMS, but you still want
pools as an interface to shared memory, to mlock()/GlobalLock()ed
memory, to this memory, to that memory, to even _files_ implemented
as memory - _whatever_, then you must code into pools the capability
to do locking of shared memory, locking of this memory, locking
of that memory, and it's just such a messy nightmare that no-one
in their right mind wishes to consider it, and i _agree_ with them :)
> (I think I asked for clarification on this, but I received none...)
whoops :) does the above help? :)
> All an sms knows how to do is to get a chunk and free a chunk of
> memory.
uh... not quite. and it knows how to manage it. keep track of
it. lock it [_if_ needed: that is up to the implementation].
_and_ the management can be done by using some _other_ sms
[parent sms] to use, which may be quicker, better, niftier,
sliced-breadier whatever.
> None of the pool logic needs to be in sms.
??? what code are you looking at? :)
you've examined the tracking memory system, yes?
and the destroy and reset?
> I saw that the sms
> were just an abstraction around allocating memory.
correct.
> The pool will
> actually handle the cleanups.
well, we have to provide cleanups in sms _anyway_.
if, as the implementor of pools, you [whoever] choose not
to leverage the functionality [sms cleanups] to make
the pools code simpler, well, then... that is your choice.
> Everyone still uses apr_pool_t.
that is correct. i would not imagine for one _second_ that
this would not be considered unless it could be done
as a #define in apr_compat.h, and even _then_ i would,
as david recommends, only slate it for some distant future
release.
> The
> pool itself uses apr_sms_t to allocate memory. This enables us to have
> a shared memory pool, a file-backed memory pool, a heap-backed memory
> pool - whatever we want.
correct.
> The sms doesn't need to do any locking - the
> pool will guarantee that the allocation is done atomically by its own
> locking mechanisms (what it does now - albeit the pool locking is a bit
> coarser than it really needs to be).
wrong. how can pools know what type of locking is required
for each type of sms it _might_ use, without turning pools into
a nightmare of spaghetti #ifdefs and #ifthatdefs that the sms
API is designed *exactly* to avoid???
see above: i explain further.
> I think the thing is that I've seen the sms as slightly different than
> what it was originally posted as.
i think that is the case, yes. either that, or we haven't
explained it enough.
concepts tend to spring from sander and i like fully-formed hydras.
getting them across without bashing heads together is an interesting
learning experience - for me, at least :)
> So, I might be in the minority here.
> I think we are seeing two different views of what an sms should be.
i hope not. i'll try to keep an eye / time on these discussions
to make sure everyone who _wants_ to know does know.
to that end, the idea was floated that perhaps those people who
wish to get together head-to-head to discuss /implement this
contact me? i have two possible venues in the u.k. where it will
be possible to invite up to... 5 people at one venue, and ...
10, maybe? at the other [50 _would_ be pushing it, a bit:
all the rooms are empty but it'd be feasible if uncomfortable :)] -
some time in july, august or september?
[hm, time to get a cable-modem, i think :) ]
all best,
luke
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> I think the thing is that I've seen the sms as slightly different than
> what it was originally posted as. So, I might be in the minority
> here. I think we are seeing two different views of what an sms should
> be.
>
> My -1 was non-veto, so it doesn't stop you. It just registers my
> dissent. -- justin
The group has told me before that, since all code matters require a
consensus, -1 always means veto. If you really, really, really don't like
it but don't want to veto it, use -0.5 or -0.99 or something. =-) Only
in non-consensus-requiring matters do -1's count as "negative votes", but
those matters seem to only exist in administrative matters, not code
matters.
<shrug>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: SMS stuff
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > Um. Hello? Have you counted the number of third party modules in
> > existence?
> > Tossing the pools means tossing the basic framework for a couple hundred
> > modules. apr_pool_t and apr_p* will remain (effectively) forever.
hiya greg,
you know that, i know that, we all know that, and so can cater for it:
it means providing a set of functions that provides exactly the
same job, exactly the same semantics, behaviour and function
arguments.
that's the _easy_ bit :)
no-one in their right mind is suggesting, not here, not ever,
never has, [but probably will, despite all the messages on
the topic], advocated doing anything that would require third
party modules to modify their code. it's just simply not..
going... to happen.
so we deal with that and take it into account in the design
and implementation.
agreed?
thx,
luke
Re: SMS stuff [long]
Posted by David Reid <dr...@jetnet.co.uk>.
Well I did say I wouldn't get back into this "debate" for a while, but...
> On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
> > > I am well beyond 100% in support of the sms schema. The only
> > > question is what is which, do we wrap the pool schema in sms,
> > > or do 'pools' become sms?
It's a question of layers really. I'd rather we just had one layer, Greg
wants to see 2, or at least that's how I view his postings. I always like
the KISS principle :)
> >
> > I'll try and write up a comparison between the apis in the weekend,
> > together with how it could be handled _if_ pools are replaced with
> > sms. If after that people are still not convinced *), I'm starting
> > to think 'we've tried. no deal. move on.'.
>
> A short description/comparison may help.
>
> However, I believe that no matter what you may end up describing, the only
> thing that people will be comfortable with is an absolute retention of
> apr_pool_t and SMS growing silently underneath that API. Certain
> applications may choose to use SMS directly (fine!). At the end point,
> apr_pool_t will be a slim cover, and we can choose what to do at that
point.
OK. I'm going to try and explain what was in our (myself and Sanders) mind
to do. Maybe this hasn't been clear before?? If so then most humble
apologies. BTW, this wasn't so much discussed as it seemed obvious
following some discussions about why they had coded some parts of sms as
they had.
At present we have a set of logic for managing memory that we call pools.
Essentially it allocates a large block and assigns smaller chunks from it
using lists to keep track of what it's done, cleaning up after it's
finished. Locking and cleanups are provided in the code and a number of
ways of getting memory are provided. However, the pools code is just that,
an implementation of a particular set of logic for dealing with memory.
It's well proven and is fast/stable and has all the other things we think a
good memory system should have, but it's logic is fixed in the code. Can we
agree with that?
Now, imagine, and until the code is written you'll have to just imagine,
that there was an sms module that implemented the same logic. The actual
details don't matter to a degree here because what we're talking about is
the same logic. The sms module takes a larger block of memory and allocates
smaller blocks from within it, cleaning up when it's no longer needed. All
the locking and cleanups are handled within the sms and we have a number of
ways of getting at the memory. So, the question becomes what is the
difference between this sms and pools? Do we still need to have the pool
logic (all the tracking, cleanups and so on) living on top of code that
already has all those things? This is what I refer to as replacing pools -
i.e. I mean replacing the implementation not the logic.
If we had such a module then we could say that
apr_sms_t == apr_pool_t
apr_palloc == apr_sms_malloc
apr_pcalloc == apr_sms_calloc
These could be, as Luke keeps pointing out, in apr_compat.h or in
apr_pools.h or wherever, but they should provide the same abilities we have
at present. If this is what Greg means by a "slim" wrapper then fair
enough, we have been talking the same language all along, but I always had
the impression he was talking about rewriting the pool code to use sms for
the allocation of memory in the pools.
Now, by having apr_pool_t == apr_sms_t we gain another big advantage - the
ability to vary the sms module to suit the situation using the same API. If
we choose to simply create a pool (which would become an sms under the
wrapper) then we get the good old pool logic we're used to with all the
cleanups and so on we'd need. However, should we want a different logic for
our memory we'd create a different type of sms, but it would still be a pool
as far as the code was concerned. Why would we want different memory?
Well, it might be that we knew the memory would be used in a single thread,
so we wanted an sms that was optimised for speed.
Now, such a thing is a big step and so progress will be slow. Having pools
logic sit on top of sms, given the above scenario seems to be restrictive to
my mind and limits what we can accomplish using the sms framework. I mean
what would the pools code become. If they are simply to become wrappers then
we're talking the same thing, but if that's the case then we should over
time start phasing the apr_pool_t out of our code. Maybe it was me seeing
this in my mind that casued me to jump a bit too far ahead in some of my
postings on this topic.
Hopefully there will be the start of such sn sms module in the codebase
before too long. the basic aim is that it should implement the same logic
as pools, have the same if not more functionality (cleanups are a big part
of that as people have kept saying) but as it's a rewrite and based on the
sms framework the hope is that it will be faster while keeping or enhancing
the stability that the pools code has. This is an ambitious target, but IF
we can achieve it (and given how many people we have here to
review/comment/improve the code I think we can), then I don't see why we'd
need the pool code anymore, just some simple typedefs and wrappers.
>
> > > Greg's argument (and I'm leaning that way) says 'pools are now
> > > widely deployed'.
I'd say "the apr_pool_t and associated API are widely deployed and in large
scale usage". Assuming that whetever we do people can still do
apr_pool_t *pool;
apr_create_pool(pool, NULL);
apr_palloc(pool, sizeof(blah));
then we won't have any problems with supporting these folks. Of course,
we'd also be able to offer people the ability to do
apr_sms_t *sms;
apr_sms_blah_create(&sms);
apr_sms_malloc(sms, sizeof(blah));
The end result would be identical if blah was the same "standard pool type"
sms we end up with. The fact is that for a user of APR to get the most
flexability from the new memory system they probably need to use the sms
API.
> >
> > I tend to disagree on that. It is 'only' deployed in httpd and
> > subversion. [not counting apr and apr-util]. If we want to change
> > things like this, now (read this as _after_ the release of
> > httpd-2.0) is the time.
>
> Um. Hello? Have you counted the number of third party modules in
existence?
> Tossing the pools means tossing the basic framework for a couple hundred
> modules. apr_pool_t and apr_p* will remain (effectively) forever.
Correct. However they don't have to point to the current pool code do they?
>
> It is entirely reasonable to assume that apr_pool_t could be a different
> name for a particular type of apr_sms_t, but there is no effective way to
> eliminate apr_pool_t and its associated functions.
Correct, but this hasn't been our intention. I think we may have been
talking cross purposes.
When I wrote
apr_pstrdup(apr_sms_t *sms, char *str)
I was assuming that somewhere we'd have (and maybe I should have pointed
this out but it was about 1am ISTR when I wrote it)
#typedef apr_pool_t apr_sms_t
So
apr_pstrdup(apr_sms_t *sms, char *str) == apr_pstrdup(apr_pool_t *p, char
*str)
The only thing I would say is that internally we should change to using the
apr_sms_t instead of apr_pool_t to emphasise that we are using sms. Which
form outside users decide to use will either be decided by legacy (they've
got so they'll keep it) or the one they feel more comfortable with.
>
> > > Grow a pool into an sms, don't break anyone's code along the way
> > > (by making the default sms our beloved pool schema) and we are in
> > > strong shape.
> >
> > There is a way to do everything _without_ breaking code along the way.
> > I'll include that in the thingy I had planned for the weekend.
Exactly.
>
> Right. I can see this, and it follows what some of us have been saying:
grow
> the SMS stuff *under* the pool abstraction. Keep pools as the top-level
API.
This is the point I don't see I guess. We should support the pool API but
we should start to move away from it wherever we can as sms offers more than
pools and keeping to a more restrictive API than we need to doesn't make a
lot of sense to me.
>
> > *) convinced is not the right word here. I'm more looking for open
> > to change, but that is also not what I'm trying to say. Damn,
> > it is hard to express yourself sometimes when you kind find the
> > words... :-)
>
> Don't worry about it. We're all convinced of particular things. But we are
> all, also open to change. If we were obstinate mother fuckers, then we
would
> never have received commit privileges. (that is the hope, at least :-)
It's just the rate of change that varies. I mean I still think the earth is
flat!
:)
david
Re: SMS stuff [long]
Posted by David Reid <dr...@jetnet.co.uk>.
Well I did say I wouldn't get back into this "debate" for a while, but...
> On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
> > > I am well beyond 100% in support of the sms schema. The only
> > > question is what is which, do we wrap the pool schema in sms,
> > > or do 'pools' become sms?
It's a question of layers really. I'd rather we just had one layer, Greg
wants to see 2, or at least that's how I view his postings. I always like
the KISS principle :)
> >
> > I'll try and write up a comparison between the apis in the weekend,
> > together with how it could be handled _if_ pools are replaced with
> > sms. If after that people are still not convinced *), I'm starting
> > to think 'we've tried. no deal. move on.'.
>
> A short description/comparison may help.
>
> However, I believe that no matter what you may end up describing, the only
> thing that people will be comfortable with is an absolute retention of
> apr_pool_t and SMS growing silently underneath that API. Certain
> applications may choose to use SMS directly (fine!). At the end point,
> apr_pool_t will be a slim cover, and we can choose what to do at that
point.
OK. I'm going to try and explain what was in our (myself and Sanders) mind
to do. Maybe this hasn't been clear before?? If so then most humble
apologies. BTW, this wasn't so much discussed as it seemed obvious
following some discussions about why they had coded some parts of sms as
they had.
At present we have a set of logic for managing memory that we call pools.
Essentially it allocates a large block and assigns smaller chunks from it
using lists to keep track of what it's done, cleaning up after it's
finished. Locking and cleanups are provided in the code and a number of
ways of getting memory are provided. However, the pools code is just that,
an implementation of a particular set of logic for dealing with memory.
It's well proven and is fast/stable and has all the other things we think a
good memory system should have, but it's logic is fixed in the code. Can we
agree with that?
Now, imagine, and until the code is written you'll have to just imagine,
that there was an sms module that implemented the same logic. The actual
details don't matter to a degree here because what we're talking about is
the same logic. The sms module takes a larger block of memory and allocates
smaller blocks from within it, cleaning up when it's no longer needed. All
the locking and cleanups are handled within the sms and we have a number of
ways of getting at the memory. So, the question becomes what is the
difference between this sms and pools? Do we still need to have the pool
logic (all the tracking, cleanups and so on) living on top of code that
already has all those things? This is what I refer to as replacing pools -
i.e. I mean replacing the implementation not the logic.
If we had such a module then we could say that
apr_sms_t == apr_pool_t
apr_palloc == apr_sms_malloc
apr_pcalloc == apr_sms_calloc
These could be, as Luke keeps pointing out, in apr_compat.h or in
apr_pools.h or wherever, but they should provide the same abilities we have
at present. If this is what Greg means by a "slim" wrapper then fair
enough, we have been talking the same language all along, but I always had
the impression he was talking about rewriting the pool code to use sms for
the allocation of memory in the pools.
Now, by having apr_pool_t == apr_sms_t we gain another big advantage - the
ability to vary the sms module to suit the situation using the same API. If
we choose to simply create a pool (which would become an sms under the
wrapper) then we get the good old pool logic we're used to with all the
cleanups and so on we'd need. However, should we want a different logic for
our memory we'd create a different type of sms, but it would still be a pool
as far as the code was concerned. Why would we want different memory?
Well, it might be that we knew the memory would be used in a single thread,
so we wanted an sms that was optimised for speed.
Now, such a thing is a big step and so progress will be slow. Having pools
logic sit on top of sms, given the above scenario seems to be restrictive to
my mind and limits what we can accomplish using the sms framework. I mean
what would the pools code become. If they are simply to become wrappers then
we're talking the same thing, but if that's the case then we should over
time start phasing the apr_pool_t out of our code. Maybe it was me seeing
this in my mind that casued me to jump a bit too far ahead in some of my
postings on this topic.
Hopefully there will be the start of such sn sms module in the codebase
before too long. the basic aim is that it should implement the same logic
as pools, have the same if not more functionality (cleanups are a big part
of that as people have kept saying) but as it's a rewrite and based on the
sms framework the hope is that it will be faster while keeping or enhancing
the stability that the pools code has. This is an ambitious target, but IF
we can achieve it (and given how many people we have here to
review/comment/improve the code I think we can), then I don't see why we'd
need the pool code anymore, just some simple typedefs and wrappers.
>
> > > Greg's argument (and I'm leaning that way) says 'pools are now
> > > widely deployed'.
I'd say "the apr_pool_t and associated API are widely deployed and in large
scale usage". Assuming that whetever we do people can still do
apr_pool_t *pool;
apr_create_pool(pool, NULL);
apr_palloc(pool, sizeof(blah));
then we won't have any problems with supporting these folks. Of course,
we'd also be able to offer people the ability to do
apr_sms_t *sms;
apr_sms_blah_create(&sms);
apr_sms_malloc(sms, sizeof(blah));
The end result would be identical if blah was the same "standard pool type"
sms we end up with. The fact is that for a user of APR to get the most
flexability from the new memory system they probably need to use the sms
API.
> >
> > I tend to disagree on that. It is 'only' deployed in httpd and
> > subversion. [not counting apr and apr-util]. If we want to change
> > things like this, now (read this as _after_ the release of
> > httpd-2.0) is the time.
>
> Um. Hello? Have you counted the number of third party modules in
existence?
> Tossing the pools means tossing the basic framework for a couple hundred
> modules. apr_pool_t and apr_p* will remain (effectively) forever.
Correct. However they don't have to point to the current pool code do they?
>
> It is entirely reasonable to assume that apr_pool_t could be a different
> name for a particular type of apr_sms_t, but there is no effective way to
> eliminate apr_pool_t and its associated functions.
Correct, but this hasn't been our intention. I think we may have been
talking cross purposes.
When I wrote
apr_pstrdup(apr_sms_t *sms, char *str)
I was assuming that somewhere we'd have (and maybe I should have pointed
this out but it was about 1am ISTR when I wrote it)
#typedef apr_pool_t apr_sms_t
So
apr_pstrdup(apr_sms_t *sms, char *str) == apr_pstrdup(apr_pool_t *p, char
*str)
The only thing I would say is that internally we should change to using the
apr_sms_t instead of apr_pool_t to emphasise that we are using sms. Which
form outside users decide to use will either be decided by legacy (they've
got so they'll keep it) or the one they feel more comfortable with.
>
> > > Grow a pool into an sms, don't break anyone's code along the way
> > > (by making the default sms our beloved pool schema) and we are in
> > > strong shape.
> >
> > There is a way to do everything _without_ breaking code along the way.
> > I'll include that in the thingy I had planned for the weekend.
Exactly.
>
> Right. I can see this, and it follows what some of us have been saying:
grow
> the SMS stuff *under* the pool abstraction. Keep pools as the top-level
API.
This is the point I don't see I guess. We should support the pool API but
we should start to move away from it wherever we can as sms offers more than
pools and keeping to a more restrictive API than we need to doesn't make a
lot of sense to me.
>
> > *) convinced is not the right word here. I'm more looking for open
> > to change, but that is also not what I'm trying to say. Damn,
> > it is hard to express yourself sometimes when you kind find the
> > words... :-)
>
> Don't worry about it. We're all convinced of particular things. But we are
> all, also open to change. If we were obstinate mother fuckers, then we
would
> never have received commit privileges. (that is the hope, at least :-)
It's just the rate of change that varies. I mean I still think the earth is
flat!
:)
david
RE: SMS stuff
Posted by Sander Striker <st...@samba-tng.org>.
> On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
> > > I am well beyond 100% in support of the sms schema. The only
> > > question is what is which, do we wrap the pool schema in sms,
> > > or do 'pools' become sms?
> >
> > I'll try and write up a comparison between the apis in the weekend,
> > together with how it could be handled _if_ pools are replaced with
> > sms. If after that people are still not convinced *), I'm starting
> > to think 'we've tried. no deal. move on.'.
>
> A short description/comparison may help.
>
> However, I believe that no matter what you may end up describing, the only
> thing that people will be comfortable with is an absolute retention of
> apr_pool_t and SMS growing silently underneath that API. Certain
> applications may choose to use SMS directly (fine!). At the end point,
> apr_pool_t will be a slim cover, and we can choose what to do at
> that point.
>
> > > Greg's argument (and I'm leaning that way) says 'pools are now
> > > widely deployed'.
> >
> > I tend to disagree on that. It is 'only' deployed in httpd and
> > subversion. [not counting apr and apr-util]. If we want to change
> > things like this, now (read this as _after_ the release of
> > httpd-2.0) is the time.
>
> Um. Hello? Have you counted the number of third party modules in
> existence?
> Tossing the pools means tossing the basic framework for a couple hundred
> modules. apr_pool_t and apr_p* will remain (effectively) forever.
>
> It is entirely reasonable to assume that apr_pool_t could be a different
> name for a particular type of apr_sms_t, but there is no effective way to
> eliminate apr_pool_t and its associated functions.
>
> > > Grow a pool into an sms, don't break anyone's code along the way
> > > (by making the default sms our beloved pool schema) and we are in
> > > strong shape.
> >
> > There is a way to do everything _without_ breaking code along the way.
> > I'll include that in the thingy I had planned for the weekend.
>
> Right. I can see this, and it follows what some of us have been
> saying: grow
> the SMS stuff *under* the pool abstraction. Keep pools as the
> top-level API.
Ah, ok, I'll describe what I have in mind. 'old' modules can retain that
api, new ones are advised to move (in my description).
> > *) convinced is not the right word here. I'm more looking for open
> > to change, but that is also not what I'm trying to say. Damn,
> > it is hard to express yourself sometimes when you kind find the
> > words... :-)
>
> Don't worry about it. We're all convinced of particular things. But we are
> all, also open to change. If we were obstinate mother fuckers,
> then we would
> never have received commit privileges. (that is the hope, at least :-)
>
> Open Source is not conducive to stubborn attitudes. People who are
> inflexible tend to be weeded out. But being flexible doesn't mean
> we have to
> /not/ have strong opinions at any point in time.
*grin* I agree.
Got to run now, I promissed to help a friend move. Bye all.
> Cheers,
> -g
Sander
Re: SMS stuff
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
> > I am well beyond 100% in support of the sms schema. The only
> > question is what is which, do we wrap the pool schema in sms,
> > or do 'pools' become sms?
>
> I'll try and write up a comparison between the apis in the weekend,
> together with how it could be handled _if_ pools are replaced with
> sms. If after that people are still not convinced *), I'm starting
> to think 'we've tried. no deal. move on.'.
A short description/comparison may help.
However, I believe that no matter what you may end up describing, the only
thing that people will be comfortable with is an absolute retention of
apr_pool_t and SMS growing silently underneath that API. Certain
applications may choose to use SMS directly (fine!). At the end point,
apr_pool_t will be a slim cover, and we can choose what to do at that point.
> > Greg's argument (and I'm leaning that way) says 'pools are now
> > widely deployed'.
>
> I tend to disagree on that. It is 'only' deployed in httpd and
> subversion. [not counting apr and apr-util]. If we want to change
> things like this, now (read this as _after_ the release of
> httpd-2.0) is the time.
Um. Hello? Have you counted the number of third party modules in existence?
Tossing the pools means tossing the basic framework for a couple hundred
modules. apr_pool_t and apr_p* will remain (effectively) forever.
It is entirely reasonable to assume that apr_pool_t could be a different
name for a particular type of apr_sms_t, but there is no effective way to
eliminate apr_pool_t and its associated functions.
> > Grow a pool into an sms, don't break anyone's code along the way
> > (by making the default sms our beloved pool schema) and we are in
> > strong shape.
>
> There is a way to do everything _without_ breaking code along the way.
> I'll include that in the thingy I had planned for the weekend.
Right. I can see this, and it follows what some of us have been saying: grow
the SMS stuff *under* the pool abstraction. Keep pools as the top-level API.
> *) convinced is not the right word here. I'm more looking for open
> to change, but that is also not what I'm trying to say. Damn,
> it is hard to express yourself sometimes when you kind find the
> words... :-)
Don't worry about it. We're all convinced of particular things. But we are
all, also open to change. If we were obstinate mother fuckers, then we would
never have received commit privileges. (that is the hope, at least :-)
Open Source is not conducive to stubborn attitudes. People who are
inflexible tend to be weeded out. But being flexible doesn't mean we have to
/not/ have strong opinions at any point in time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SMS stuff
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> Greg's argument (and I'm leaning that way) says 'pools are now widely deployed'.
> Grow a pool into an sms, don't break anyone's code along the way (by making the
> default sms our beloved pool schema) and we are in strong shape.
yaaay :)
[btw, i'm sorry i got so stressed yesterday: seeing so
many messages that looked like they had the wrong end
of the stick, i threw progressively harder words about
as i read more and more. sorry for any fingers burnt. luke]
RE: SMS stuff
Posted by Sander Striker <st...@samba-tng.org>.
> I am well beyond 100% in support of the sms schema. The only
> question is what is which, do we wrap the pool schema in sms,
> or do 'pools' become sms?
I'll try and write up a comparison between the apis in the weekend,
together with how it could be handled _if_ pools are replaced with
sms. If after that people are still not convinced *), I'm starting
to think 'we've tried. no deal. move on.'.
> Greg's argument (and I'm leaning that way) says 'pools are now
> widely deployed'.
I tend to disagree on that. It is 'only' deployed in httpd and
subversion. [not counting apr and apr-util]. If we want to change
things like this, now (read this as _after_ the release of
httpd-2.0) is the time.
> Grow a pool into an sms, don't break anyone's code along the way
> (by making the default sms our beloved pool schema) and we are in
> strong shape.
There is a way to do everything _without_ breaking code along the way.
I'll include that in the thingy I had planned for the weekend.
> Bill
Sander
*) convinced is not the right word here. I'm more looking for open
to change, but that is also not what I'm trying to say. Damn,
it is hard to express yourself sometimes when you kind find the
words... :-)
Re: SMS stuff
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "David Reid" <dr...@jetnet.co.uk>
Sent: Wednesday, June 06, 2001 5:19 PM
> We could implement pool using sms but we'd loose a great deal of flexibility
> and a great opportunity to make APR even more useful.
>
> As each sms has the opportunity to control exactly how it locks, allocates,
> frees and so on they have enormous potential to be varied and written for
> specific purposes, each one optimised. This means we have a memory system
> that can be tailored, so one size doesn't have to suit everyone.
>
> What's the difference to pools? You are in control of how the memory is
> used. Pools don't really give you that. do we need that flexibility?
> Well, given we have the opportunity and my magic ball is out of warranty,
> I'd say Yes. Justin it would appear says No.
Just a word from here, yes. This is the way to go.
Every quality library provides a fn hook for the malloc and free functions
(such as regex, expat, and many many more.) The sms design takes that one
(very thorough) step beyond.
...
From: "David Reid" <dr...@jetnet.co.uk>
Sent: Thursday, June 07, 2001 4:19 AM
> Don't believe that was how it happenned at all. I was very much a cynic
> when I started looking at the sms stuff. The way that afew people started
> raving on about how cool it all was made me shudder and that was why I
> looked at it in such detail. The reviewing of the code an opening my mind
> to the possibilities made me see where it could go. To be perfectly blunt
> Sanders constant evangelising made me more anti sms than pro it. It was the
> code that convinced me it could do a lot for APR :( But you weren't to know
> that as it's not something I've said to people before.
Just had to say it, you don't think we notice such things ??? I was actually
very impressed to see the 'system', al la open source development, work so
effectively and quickly! I actually expected you to say something along these
lines a week or few ago ;-)
> Well, I'll try, but I guess if this horse is dead then we may as well bury
> it :( I'd hate to think that we'd do that at this stage as more work should
> be done to try and justify the potential that some of us see in sms. That
> said if the door has already been bolted then the effort that would be
> wasted in developing sms further would be just that, wasted, so we should
> move on... Oops, was this really a "glass half full" statement... :=)
I find it amusing that, reading back three months, David, you were the EXTREME
sceptic :-) This horse isn't dead, and these are [similar to] the distinctions
between "The Two Filter Schemas". A ton of that debate was over semantics, and
very little had to do with the philosophy. And we ended up with a solution par
excelante because of the thoroughness of the debates.
I am well beyond 100% in support of the sms schema. The only question is what
is which, do we wrap the pool schema in sms, or do 'pools' become sms?
Greg's argument (and I'm leaning that way) says 'pools are now widely deployed'.
Grow a pool into an sms, don't break anyone's code along the way (by making the
default sms our beloved pool schema) and we are in strong shape.
Bill
Re: cvs commit: apr/threadproc/unix thread.c
Posted by David Reid <dr...@jetnet.co.uk>.
> > > Argh! I also thought that the purpose of SMS was to replace
malloc/free
> > > and not pools. If you want to replace pools, then the code should not
> > > be called apr_sms_blah. Pool is the name for our memory system --
pool
> > > does not, and never has, defined the type of memory behind it.
> >
> > pool is the name of the _current_ memory system. There will be a
> > sms called pool aswell. You get a pool like system by doing
> > apr_sms_pool_create() [this is still a todo, but I'm working on it].
>
> I don't think you are following my drift. There exists a memory system
> within APR. It is called a pool. If anyone here attempts to replace the
> HIDDEN INTERNALS of that memory system with some new sms thingy and then
> suggests that we should change all calls to apr_pool with apr_sms_pool,
> I am going to throttle them with a baseball bat (and then -1 the patch).
Ouch. :)
>
> We have an abstraction. We will have the same abstraction with sms.
> Therefore, either sms is under pool or it is a replacement for the hidden
> internals of pool with some extensions that are new. It seems to make
more
> sense as a replacement, which means we code it as such and not as some
> "other" memory system. That means we use the same names and selectively
> compile one of the two choices into apr until we are sure that the old one
> can be replaced with the new one.
>
> Under no circumstances whatsoever will we change all of our code to call
> sms things just because they were implemented as a superset of the current
> pool internals. That defeats the whole purpose of abstract data types.
OK. This seems like a good idea.
>
> > Second, with a different namespace we _can_ retain the current pools
> > api (at least long enough) next to the sms api. In the httpd, apr
> > and apr-util codebase the sms api would be preferred.
>
> Cruft shall not be carried forward unless it is necessary for backwards
> compatibility.
>
> > > Just use the same names as apr_pool.c and selectively compile one or
> > > the other.
> >
> > The fun is that you don't have to compile one in, you could decide at
> > runtime if you please.
So, possible roadmap for moving forward...
- keep working on the sms code as apr_sms for the time being. We keep doing
this until we have an sms module that could replace the current pool code.
- build into configure a switch for new/old pool code, keeping the default
as the current code
- move the pools.c file into the memory/unix directory and add logic to
Makefile.in to build pools.c or the sms stuff
o at the same time change the top level API's for the sms code to look
like apr_pool_t semantics
o remove the lib directory
- contiue development and add to the API such that we have the full range of
flexability of the sms concept but called apr_pool_t
- when we're ready change the default option in APR to the new code
Carrying on what's been started in the sms code under a seperate namespace
should mean we don't cause too much grief until we're ready to make the
move.
I'm only suggesting moving the pools.c file as that way all memory files are
in a single location which seems to make more sense. IN fact it might make
more sense to have the top level apr_sms.c file in the memory directory and
the seperate sms modules in the platform specific directories. We can
debate this but I don't care one way or the other.
>
> There is nothing fun about bloated runtimes.
Indeed.
If people are happy with this then this is how we'll proceed and in a while
when we're ready to move to stage 2 we'll no doubt have another discussion
about the exact details of how we do things :) We do like talking don't
we?? Of course some of us prefer words to baseball bats Roy :))
david
Re: cvs commit: apr/threadproc/unix thread.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > Argh! I also thought that the purpose of SMS was to replace malloc/free
> > and not pools. If you want to replace pools, then the code should not
> > be called apr_sms_blah. Pool is the name for our memory system -- pool
> > does not, and never has, defined the type of memory behind it.
>
> pool is the name of the _current_ memory system. There will be a
> sms called pool aswell. You get a pool like system by doing
> apr_sms_pool_create() [this is still a todo, but I'm working on it].
I don't think you are following my drift. There exists a memory system
within APR. It is called a pool. If anyone here attempts to replace the
HIDDEN INTERNALS of that memory system with some new sms thingy and then
suggests that we should change all calls to apr_pool with apr_sms_pool,
I am going to throttle them with a baseball bat (and then -1 the patch).
We have an abstraction. We will have the same abstraction with sms.
Therefore, either sms is under pool or it is a replacement for the hidden
internals of pool with some extensions that are new. It seems to make more
sense as a replacement, which means we code it as such and not as some
"other" memory system. That means we use the same names and selectively
compile one of the two choices into apr until we are sure that the old one
can be replaced with the new one.
Under no circumstances whatsoever will we change all of our code to call
sms things just because they were implemented as a superset of the current
pool internals. That defeats the whole purpose of abstract data types.
> Second, with a different namespace we _can_ retain the current pools
> api (at least long enough) next to the sms api. In the httpd, apr
> and apr-util codebase the sms api would be preferred.
Cruft shall not be carried forward unless it is necessary for backwards
compatibility.
> > Just use the same names as apr_pool.c and selectively compile one or
> > the other.
>
> The fun is that you don't have to compile one in, you could decide at
> runtime if you please.
There is nothing fun about bloated runtimes.
....Roy
RE: cvs commit: apr/threadproc/unix thread.c
Posted by Sander Striker <st...@samba-tng.org>.
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > We could implement pool using sms but we'd loose a great deal
> > of flexibility
> > and a great opportunity to make APR even more useful.
> >
> > Pools are a single way of dealing with handing out memory. they imply a
> > degree of overhead and while they work eveyrwhere there is some
> > degree of agreement that they're overkill in a lot of cases. So why do
it?
>
> Argh! I also thought that the purpose of SMS was to replace malloc/free
> and not pools. If you want to replace pools, then the code should not
> be called apr_sms_blah. Pool is the name for our memory system -- pool
> does not, and never has, defined the type of memory behind it.
pool is the name of the _current_ memory system. There will be a
sms called pool aswell. You get a pool like system by doing
apr_sms_pool_create() [this is still a todo, but I'm working on it].
> The current pool code is completely screwed for threaded environments
> because of the mutex locks. httpd 2.0 will not be production ready on
> threaded servers until we can get rid of that locking within worker pools.
> If the solution to that is to replace pools with sms, then let's get
> to it, but we should do so without creating a new sms namespace.
Well, it is very hard to avoid that, because the sms api is more
'advanced' as the pools api. What can be done is retaining the pools
api in terms of sms. For example like this:
#define apr_pool_t apr_sms_t
#define apr_pool_create(sms, parent) apr_sms_pool_create(sms, parent)
#define apr_palloc(sms, size) apr_sms_malloc(sms, size)
#define apr_pcalloc(sms, size) apr_sms_calloc(sms, size)
#define apr_prealloc(sms, mem, size) apr_sms_realloc(sms, mem, size)
#define apr_pool_clear(sms) apr_sms_reset(sms)
#define apr_pool_destroy(sms) apr_sms_destroy(sms)
In the same way cleanups can be done, but they don't match one on
one [the sms cleanup system is meant to be more generic. There are
still some tricks that need to be implemented, but we'll get to that]
Second, with a different namespace we _can_ retain the current pools
api (at least long enough) next to the sms api. In the httpd, apr
and apr-util codebase the sms api would be preferred.
> Just use the same names as apr_pool.c and selectively compile one or
> the other.
The fun is that you don't have to compile one in, you could decide at
runtime if you please.
> .....Roy
Sander
PS. How things were envisioned changed along the way, but IMHO that isn'y
necessarily a bad thing...
Re: cvs commit: apr/threadproc/unix thread.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> We could implement pool using sms but we'd loose a great deal of flexibility
> and a great opportunity to make APR even more useful.
>
> Pools are a single way of dealing with handing out memory. they imply a
> degree of overhead and while they work eveyrwhere there is some degree of
> agreement that they're overkill in a lot of cases. So why do it?
Argh! I also thought that the purpose of SMS was to replace malloc/free
and not pools. If you want to replace pools, then the code should not
be called apr_sms_blah. Pool is the name for our memory system -- pool
does not, and never has, defined the type of memory behind it.
The current pool code is completely screwed for threaded environments
because of the mutex locks. httpd 2.0 will not be production ready on
threaded servers until we can get rid of that locking within worker pools.
If the solution to that is to replace pools with sms, then let's get
to it, but we should do so without creating a new sms namespace.
Just use the same names as apr_pool.c and selectively compile one or
the other.
....Roy
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > This isn't possible with pools. They limit you to a single way of getting
> > at your memory regardless of how it was obtained.
>
> What I basically said in my email to David was that I could see having a
> pool take in an option as to which SMS it should use. I've said this
> before a few weeks ago (probably when I first looked at the SMS code),
> but let me reiterate that suggestion. Obviously, there would be a
> default SMS that would be used, if one isn't provided when the pool is
> created.
>
> I think that this allows the SMS code to be kept simple, while the pool
> code can be kept relatively similar to what it does now.
>
> I'll shut up for a while on this. -- justin
:)
perhaps i should re-iterate / confirm that what justin says, above,
is exactly how i envisioned SMS to be used.
more than that, it can even be hidden behind apr_initialise().
the initial call to create the initial pool does not even need
to _take_ an extra sms argument: by _default_ the existing
apr_pool_create() function just... uses the standard-memory sms.
now, if you don't _want_ a pool that use the standard-memory sms,
you call, uh... say, apr_pool_create_from_sms() - which is what
justin above recommends be actually called apr_pool_create().
i'll shut up too because i'm probably confusing matters by not
exactly knowing the total internal workings of apr.
yet.
luke
Re: SMS stuff
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> Well, we'll agree to differ on these. The basic problem is that they're all
> the same method for allocating memory, all that varies is where the memory
> comes from. Hell, if that's all we want to do then why are we bothering
> with sms? sms adds a lot of baggage if all we really want is to be able to
> slot in a backend!
remember that one of the suggestions i made was to create
a mem-locked SMS, for security of encryption / storage of
private keys (using techniques / code already in GPG).
the basic premise is that pretty much all code uses pools.
therefore, in order to fulfil the requirements,
you back-end pools with the appropriate sms as it's
a self-contained location in the code dependency-order.
luke
Re: SMS stuff
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> Here is why I thought that:
>
> David Reid wrote:
> > When we're done we'll have
> >
> > locks -> apr_sms_t
> > sms -> locks -> apr_sms_t
> >
> > So personally I don't see the problem and thus I made the change! I guess
> > maybe it's because people keep saying that we're going to change the pools
> > to use sms. Why? To get the maximum flexibility we'll need to use sms
> > throughout so while we may have
> >
> > apr_pstrdup(apr_pool_t *pool, char *str)
> >
> > we'll end up with
> >
> > apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
>
> So no wonder I'm a bit concerned.
ack.
... okay. doing a half-way-house isn't going to satisfy you,
me, or anybody. david clarified in a later post,
on the above.
sander's written up a roadmap that outlines what me, sander
and david agree on, and it takes into consideration
everyone's concerns: that's my take on it, anyway.
> I haven't complained about the code one bit. Yes, it is simple, but reading
> it isn't change what I'm talking about... I have an issue with what we're
> going to *do* with it. And given that I believe SMS with providing storage
> for a pool,
ack.
> then I question why we have a pool underneath an SMS.
me, too, don't worry! :)
okay, there are two approaches to do
"SMS with providing storage for a pool"
1) implement apr_pool.c to call functions in apr_sms
2) provide exactly the same functionality and then #define.
if 1) just becomes a thin wrapper, then it's pointless function
overhead and you might as well do 2) _anyway_!
luke
Re: SMS stuff
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jun 07, 2001 at 03:35:14PM +0200, Luke Kenneth Casson Leighton wrote:
> > > Point out that requirement, and you can change a lot of minds here. But
> > > until then, I think you'll continue to see confused/concerned people, not
> > > understanding why you are suggesting we toss all of the memory management
> > in
> > > APR in favor of SMS.
>
> uh, sorry to have to point this out like this, but your understanding
> of the original plan for SMS usage is plain wrong.
>
> i have no idea what makes you think that anyone is suggesting that
> all mman in APR is 'tossed' in favour of sms, and if anyone
> else recommends it i will bitch at them persistently until they give
> a decent justification, or give up. :)
Here is why I thought that:
David Reid wrote:
> When we're done we'll have
>
> locks -> apr_sms_t
> sms -> locks -> apr_sms_t
>
> So personally I don't see the problem and thus I made the change! I guess
> maybe it's because people keep saying that we're going to change the pools
> to use sms. Why? To get the maximum flexibility we'll need to use sms
> throughout so while we may have
>
> apr_pstrdup(apr_pool_t *pool, char *str)
>
> we'll end up with
>
> apr_pstrdup(apr_sms_t *mem_sys, char *str)
So no wonder I'm a bit concerned.
>...
> please, like david did, if you don't like or don't understand
> the explanations, please read the code. it's really short,
> it's really simple - and it's short and simple _because_ we
> [collectively - all of us] have enough experience to realise
> that anything else will cause us to have nightmares until the
> code's ripped out and burnt. ritually.
I haven't complained about the code one bit. Yes, it is simple, but reading
it isn't change what I'm talking about... I have an issue with what we're
going to *do* with it. And given that I believe SMS with providing storage
for a pool, then I question why we have a pool underneath an SMS.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SMS stuff
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > Point out that requirement, and you can change a lot of minds here. But
> > until then, I think you'll continue to see confused/concerned people, not
> > understanding why you are suggesting we toss all of the memory management
> in
> > APR in favor of SMS.
uh, sorry to have to point this out like this, but your understanding
of the original plan for SMS usage is plain wrong.
i have no idea what makes you think that anyone is suggesting that
all mman in APR is 'tossed' in favour of sms, and if anyone
else recommends it i will bitch at them persistently until they give
a decent justification, or give up. :)
_one_ of the suggestions was to create functions in sms that
are identical to those of pools except with different names and
different types. _one_ [then you add into apr_compat.h
#defines to move them to the new types]
you don't have to take or do that suggestion, esp. as this is
an easy-does-it approach.
please, like david did, if you don't like or don't understand
the explanations, please read the code. it's really short,
it's really simple - and it's short and simple _because_ we
[collectively - all of us] have enough experience to realise
that anything else will cause us to have nightmares until the
code's ripped out and burnt. ritually.
:)
luke
RE: SMS stuff
Posted by Sander Striker <st...@samba-tng.org>.
[...]
> Sanders constant evangelising made me more anti sms than pro it.
*whoops* I tend to do that sometimes when I really have a good
gut feeling about something. I is not supposed to have a negative
effect though. [I must say that I am a bit blind for scepticism,
I see it more as questions that need to be answered and it is
just that that seems to tick people off]
> It was the code that convinced me it could do a lot for APR :(
> But you weren't to know that as it's not something I've said
> to people before.
Not even me. People, if I'm in evangelist mode, please drop me a
line.
Thx,
Sander
Re: SMS stuff
Posted by David Reid <dr...@jetnet.co.uk>.
Greg,
> On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote:
> > On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > > This isn't possible with pools. They limit you to a single way of
getting
> > > at your memory regardless of how it was obtained.
> >
> > What I basically said in my email to David was that I could see having a
>
> All right. This has to stop.
>
> David, Sander: bring your conversations onto THIS list. You cannot
continue
> to have conversations in private, develop code in the public APR(UTIL)
tree,
> and then expect us to /not/ participate (review, vote, tweak, patch).
To be honest the "issues" that have come up have been on the list before
solutions were committed :( we are al busy people and reading every email
in total detail takes a large amount of time.
The basic reason for holding discussions in private is that they have been
extremely theoretical and don't have any code associated with them, nor will
they ever. They also tended to be long and drawn out - not ideal list
material :(
However, point taken.
>
> The SMS stuff is in APR now, so we are all involved. Keeping conversations
> private is simply going to keep these disconnects happening in the future.
Yes.
>
> At the moment, we have a big group of people who see SMS as a substrate
for
> pools. However, there is a smaller group (David and Sander) who see SMS as
> the end-goal, replacing pools, and that pools will eventually go away.
>
> How did this disconnect happen? Because you guys talked in private, rather
> than with the rest of the group.
Don't believe that was how it happenned at all. I was very much a cynic
when I started looking at the sms stuff. The way that afew people started
raving on about how cool it all was made me shudder and that was why I
looked at it in such detail. The reviewing of the code an opening my mind
to the possibilities made me see where it could go. To be perfectly blunt
Sanders constant evangelising made me more anti sms than pro it. It was the
code that convinced me it could do a lot for APR :( But you weren't to know
that as it's not something I've said to people before.
> </rant>
>
> > pool take in an option as to which SMS it should use. I've said this
> > before a few weeks ago (probably when I first looked at the SMS code),
> > but let me reiterate that suggestion. Obviously, there would be a
> > default SMS that would be used, if one isn't provided when the pool is
> > created.
>
> Exactly. This was my thought, too, so seeing a pool go *inside* of an SMS
> system is whacky.
Why? sms and pools allocate memory. A pool is just a specific system for
allocating that at present APR uses throughout, hence we're just adding more
capability to sms. Don't really see why that is whacky.
>
> >...
> > IMHO, using APR without something that implements cleanup routines (like
> > what the pool does now) is going to be troublesome to implement without
> > rearchitecting the guts of APR.
Sms has more options for cleanup's than pools. Sander added a scope
variable so we can do selective cleanup's of children or even within
children. Given that sms also has a well defined parent/child structure
then this should make our memory easier to cleanup, not harder. I will
admit that not a lot has been to develop that side more, but the code is
still only a month or so old...
There has never been any notion that sms wouldn't have cleanup's so I'm not
sure where this came from. Perhaps because there is an apr_sms_free
function?
>
> Right on the money. APR is built around pools. There is no reason to even
> attempt to believe that it will be built any other way for a while. APR
2.0
> could have a different system, but for the next year... we're using pools.
This isn't/has never been in dispute. I wouldn't consider replacing pools
in the near future and am -1 on replacing them before we have a release of
apache 2.0. sms is a longer term plan.
>
> ----
>
> David said that SMS gives us flexibility that pools don't have. He
suggests
> a few things:
>
> > You want a single block of long lived memory, great use the standard
> > allocator.
> > You want high performance, low footprint memory, use a pool like system.
> > You want simple shared memory, use a shared meory sms.
> > You want higher performance shared meory, use a tracking sms as a child
of a
> > shared sms.
> > etc etc
>
> Single block of long-lived memory: the global pool (or some other
long-lived
> pool)
>
> High perf: use a pool
>
> Simple shared memory: a pool which uses a shared memory SMS for allocating
> its memory.
>
> High perf: already have it
>
Well, we'll agree to differ on these. The basic problem is that they're all
the same method for allocating memory, all that varies is where the memory
comes from. Hell, if that's all we want to do then why are we bothering
with sms? sms adds a lot of baggage if all we really want is to be able to
slot in a backend!
>
> For the few times when we need to alloc/free at a granular level, then
> apr_pool_create() / apr_pool_destroy() are more than sufficient.
So we create the lists, destroy the lists, all just to free a few bytes.
Seems clumbsy and overkill to me. A pool is a whole management system, not
just a piece of memory. That system has overhead which isn't always needed.
>
> I am not seeing a large justification for transforming the entire APR
> library (and bubbling that up into Apache, Subversion, etc). The SMS
> alternative systems seem to be able to fit under the pool abstraction.
>
Well, if that's all we'll ever use sms for then let's ditch it now as it's a
distraction. sms offers much more than that and we don't need it.
>
> Now, it is abundantly clear that a few of us are seeing it this way. What
we
> don't understand is what forces it to go the other way? Why does SMS need
to
> be the top-level abstraction? A simple explanation here would go a long
ways.
>
> For example, "you simple cannot do <X> with a pool, but you do it <THIS>
way
> with SMS."
Well, I'll try, but to be honest your views seem to be pretty well
entrenched :( However, I'm in "glass half full" mode so we'll see :)
- every time we create a pool we have to go through and lock the
alloc_mutex. the code is designed for genral usage and this is required.
With the lock changes this will get faster, but it'll still be there.
Justin pointed out that during connections we really are in a single thread,
so no locking is required. Also at the end of the connection we'll ditch
the whole thing and start over. Why not have a simple sms module that
doesn't have any locking and simply allocates memory directly from a single
large lump? We don't even nee to track it as at the end of the connection
we'll just call reset and memset the whole block to 0. It should be faster
than pools.
- Cliff says that for the bucket code they want a different way of getting
memory, using thread id's. In pools we have to allocate a pool and then use
a table or some such to associate blocks from that pool with thread ids,
whereas with sms we simply write a sms module that has the management of
thread ids built in, vastly simplifying things for the bucket code.
2 examples that have come up in the past 24 hours... They may not be the
best ones, but they are ones that have been suggested/implied by people
other than Sander/myself.
I gues what I see as the big advantage of sms is that it gives you a blank
sheet of paper for your memory. You can write a very specific sms module
(as will be done for the buckets) with all sorts of optimisations/features
that pools just don't let you. Pools always control the memory in a
particular way. They have a set structure and that can't be easily changed.
You want to have refcounting for each allocation - implement it on top of
your pools. In sms you want refcounting, write the code and integrate it
entirely. You want specific functions for getting at it, not a problem just
add them for your sms module.
That's why it's important that the locking is done at sms level. If you
don't need locking you'll uses a non locking sms module. Why go passing in
variables when we don't really need to?
As the author of a piece of code you should know what sort of memory
management you need. We'll hopefully end up with an array of modules that
you can choose from, an if the one you want isn't there, write a new one!
Whilst this is possible with pools you're adding another layer on top, with
sms you're not.
> Point out that requirement, and you can change a lot of minds here. But
> until then, I think you'll continue to see confused/concerned people, not
> understanding why you are suggesting we toss all of the memory management
in
> APR in favor of SMS.
Well, I'll try, but I guess if this horse is dead then we may as well bury
it :( I'd hate to think that we'd do that at this stage as more work should
be done to try and justify the potential that some of us see in sms. That
said if the door has already been bolted then the effort that would be
wasted in developing sms further would be just that, wasted, so we should
move on... Oops, was this really a "glass half full" statement... :=)
david
SMS stuff (was: Re: cvs commit: apr/threadproc/unix thread.c)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > This isn't possible with pools. They limit you to a single way of getting
> > at your memory regardless of how it was obtained.
>
> What I basically said in my email to David was that I could see having a
All right. This has to stop.
David, Sander: bring your conversations onto THIS list. You cannot continue
to have conversations in private, develop code in the public APR(UTIL) tree,
and then expect us to /not/ participate (review, vote, tweak, patch).
The SMS stuff is in APR now, so we are all involved. Keeping conversations
private is simply going to keep these disconnects happening in the future.
At the moment, we have a big group of people who see SMS as a substrate for
pools. However, there is a smaller group (David and Sander) who see SMS as
the end-goal, replacing pools, and that pools will eventually go away.
How did this disconnect happen? Because you guys talked in private, rather
than with the rest of the group.
</rant>
> pool take in an option as to which SMS it should use. I've said this
> before a few weeks ago (probably when I first looked at the SMS code),
> but let me reiterate that suggestion. Obviously, there would be a
> default SMS that would be used, if one isn't provided when the pool is
> created.
Exactly. This was my thought, too, so seeing a pool go *inside* of an SMS
system is whacky.
>...
> IMHO, using APR without something that implements cleanup routines (like
> what the pool does now) is going to be troublesome to implement without
> rearchitecting the guts of APR.
Right on the money. APR is built around pools. There is no reason to even
attempt to believe that it will be built any other way for a while. APR 2.0
could have a different system, but for the next year... we're using pools.
----
David said that SMS gives us flexibility that pools don't have. He suggests
a few things:
> You want a single block of long lived memory, great use the standard
> allocator.
> You want high performance, low footprint memory, use a pool like system.
> You want simple shared memory, use a shared meory sms.
> You want higher performance shared meory, use a tracking sms as a child of a
> shared sms.
> etc etc
Single block of long-lived memory: the global pool (or some other long-lived
pool)
High perf: use a pool
Simple shared memory: a pool which uses a shared memory SMS for allocating
its memory.
High perf: already have it
For the few times when we need to alloc/free at a granular level, then
apr_pool_create() / apr_pool_destroy() are more than sufficient.
I am not seeing a large justification for transforming the entire APR
library (and bubbling that up into Apache, Subversion, etc). The SMS
alternative systems seem to be able to fit under the pool abstraction.
Now, it is abundantly clear that a few of us are seeing it this way. What we
don't understand is what forces it to go the other way? Why does SMS need to
be the top-level abstraction? A simple explanation here would go a long ways.
For example, "you simple cannot do <X> with a pool, but you do it <THIS> way
with SMS."
Point out that requirement, and you can change a lot of minds here. But
until then, I think you'll continue to see confused/concerned people, not
understanding why you are suggesting we toss all of the memory management in
APR in favor of SMS.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> This isn't possible with pools. They limit you to a single way of getting
> at your memory regardless of how it was obtained.
What I basically said in my email to David was that I could see having a
pool take in an option as to which SMS it should use. I've said this
before a few weeks ago (probably when I first looked at the SMS code),
but let me reiterate that suggestion. Obviously, there would be a
default SMS that would be used, if one isn't provided when the pool is
created.
I think that this allows the SMS code to be kept simple, while the pool
code can be kept relatively similar to what it does now.
IMHO, using APR without something that implements cleanup routines (like
what the pool does now) is going to be troublesome to implement without
rearchitecting the guts of APR.
I'll shut up for a while on this. -- justin
Re: cvs commit: apr/threadproc/unix thread.c
Posted by David Reid <dr...@jetnet.co.uk>.
I've just replied to Justin direct, but I'll say it here as well...
We could implement pool using sms but we'd loose a great deal of flexibility
and a great opportunity to make APR even more useful.
Pools are a single way of dealing with handing out memory. they imply a
degree of overhead and while they work eveyrwhere there is some degree of
agreement that they're overkill in a lot of cases. So why do it?
SMS gives us a very great deal of flexability.
You want a single block of long lived memory, great use the standard
allocator.
You want high performance, low footprint memory, use a pool like system.
You want simple shared memory, use a shared meory sms.
You want higher performance shared meory, use a tracking sms as a child of a
shared sms.
etc etc
This isn't possible with pools. They limit you to a single way of getting
at your memory regardless of how it was obtained.
As each sms has the opportunity to control exactly how it locks, allocates,
frees and so on they have enormous potential to be varied and written for
specific purposes, each one optimised. This means we have a memory system
that can be tailored, so one size doesn't have to suit everyone.
Take apache...
top level pool doesn't really change much, is only alloacted at startup, so
it could be a simple, low overhead standard sms.
pool for connection data - rapidly changing, performance more important than
overhead, use a tracking sms.
ssl certificates, needed by all processes but don't change very often,
simple shared sms
Imagine a crude caching sms. You create it with a default time for each
allocation. It could start a thread that cleaned up the memory when the
time expired, all without the app needing to be bothered beyond it's initial
allocation. Do we want such a thing, probably not but it could be
written/used easily using sms, more difficult using pools.
What's the difference to pools? You are in control of how the memory is
used. Pools don't really give you that. do we need that flexibility?
Well, given we have the opportunity and my magic ball is out of warranty,
I'd say Yes. Justin it would appear says No.
Time for bed.
david
> > On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > > This is the crux of the issue methinks. We don't yet have a module
that
> > > would allow us to even get close to replacing pools. We need a lot of
> > > things from it and Sander and I have had some good early
> > discussions about
> > > how it could work. Basically we want to have a fast, stable tracking
> > > allocator that has a smaller memory footprint than pools. Is
> > it possible?
> > > I don't honestly know but we're going to give it a good try.
> > Why haven't we
> > > opened up our discussions? Because we haven't even got any code and
are
> > > still bashing around the early design which is probably better done
> > > privately. Once we have something we like we'll post.
>
> I agree.
>
> > See, I think this is the difference. I see that the pools are on top of
> > sms. (Gee, this is what Cliff said...) The sms doesn't need to know
> > anything about refcounting or anything special. What does refcounting
> > give you? I'm still not also sure why locking needs to be in the SMS.
> > (I think I asked for clarification on this, but I received none...)
>
> See below and previous messages.
>
> > All an sms knows how to do is to get a chunk and free a chunk of
> > memory. None of the pool logic needs to be in sms. I saw that the sms
> > were just an abstraction around allocating memory.
>
> And cleanups... And some other stuff that is in the works.
>
> > The pool will
> > actually handle the cleanups. Everyone still uses apr_pool_t. The
> > pool itself uses apr_sms_t to allocate memory.
>
> Which gives us another level of indirection that is just not necessary.
> The sms framework can already pretty much handle what pools can handle.
> There are just a few sms implementations to be written like the ones
> you mention below.
>
> > This enables us to have
> > a shared memory pool, a file-backed memory pool, a heap-backed memory
> > pool - whatever we want.
>
> Replace pool with sms in the previous lines and you are right on the
> money :-)
>
> > The sms doesn't need to do any locking - the
> > pool will guarantee that the allocation is done atomically by its own
> > locking mechanisms (what it does now - albeit the pool locking is a bit
> > coarser than it really needs to be).
>
> If this is the general consent we might aswell have added a few function
> pointers (for alloc/realloc/free) to apr_pool_t and be done with it. We
> wanted to do the entire thing without being held back by previous design.
> Also, sms was designed independent of apr, it was inspired on glances on
> the apr library (mostly the documentation :-).
>
> > I think the thing is that I've seen the sms as slightly different than
> > what it was originally posted as. So, I might be in the minority here.
> > I think we are seeing two different views of what an sms should be.
>
> Yes, I think we need to get this sync'ed up. However, this seems to
> take some time, so implementing some things on our side and then showing
> what it does, why and how it is supposes to be used can be dealt with
> after that. I really don't like selling air :-)
>
> > My -1 was non-veto, so it doesn't stop you. It just registers my
> > dissent. -- justin
RE: cvs commit: apr/threadproc/unix thread.c
Posted by Sander Striker <st...@samba-tng.org>.
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks. We don't yet have a module that
> > would allow us to even get close to replacing pools. We need a lot of
> > things from it and Sander and I have had some good early
> discussions about
> > how it could work. Basically we want to have a fast, stable tracking
> > allocator that has a smaller memory footprint than pools. Is
> it possible?
> > I don't honestly know but we're going to give it a good try.
> Why haven't we
> > opened up our discussions? Because we haven't even got any code and are
> > still bashing around the early design which is probably better done
> > privately. Once we have something we like we'll post.
I agree.
> See, I think this is the difference. I see that the pools are on top of
> sms. (Gee, this is what Cliff said...) The sms doesn't need to know
> anything about refcounting or anything special. What does refcounting
> give you? I'm still not also sure why locking needs to be in the SMS.
> (I think I asked for clarification on this, but I received none...)
See below and previous messages.
> All an sms knows how to do is to get a chunk and free a chunk of
> memory. None of the pool logic needs to be in sms. I saw that the sms
> were just an abstraction around allocating memory.
And cleanups... And some other stuff that is in the works.
> The pool will
> actually handle the cleanups. Everyone still uses apr_pool_t. The
> pool itself uses apr_sms_t to allocate memory.
Which gives us another level of indirection that is just not necessary.
The sms framework can already pretty much handle what pools can handle.
There are just a few sms implementations to be written like the ones
you mention below.
> This enables us to have
> a shared memory pool, a file-backed memory pool, a heap-backed memory
> pool - whatever we want.
Replace pool with sms in the previous lines and you are right on the
money :-)
> The sms doesn't need to do any locking - the
> pool will guarantee that the allocation is done atomically by its own
> locking mechanisms (what it does now - albeit the pool locking is a bit
> coarser than it really needs to be).
If this is the general consent we might aswell have added a few function
pointers (for alloc/realloc/free) to apr_pool_t and be done with it. We
wanted to do the entire thing without being held back by previous design.
Also, sms was designed independent of apr, it was inspired on glances on
the apr library (mostly the documentation :-).
> I think the thing is that I've seen the sms as slightly different than
> what it was originally posted as. So, I might be in the minority here.
> I think we are seeing two different views of what an sms should be.
Yes, I think we need to get this sync'ed up. However, this seems to
take some time, so implementing some things on our side and then showing
what it does, why and how it is supposes to be used can be dealt with
after that. I really don't like selling air :-)
> My -1 was non-veto, so it doesn't stop you. It just registers my
> dissent. -- justin
Ack.
Sander
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> This is the crux of the issue methinks. We don't yet have a module that
> would allow us to even get close to replacing pools. We need a lot of
> things from it and Sander and I have had some good early discussions about
> how it could work. Basically we want to have a fast, stable tracking
> allocator that has a smaller memory footprint than pools. Is it possible?
> I don't honestly know but we're going to give it a good try. Why haven't we
> opened up our discussions? Because we haven't even got any code and are
> still bashing around the early design which is probably better done
> privately. Once we have something we like we'll post.
See, I think this is the difference. I see that the pools are on top of
sms. (Gee, this is what Cliff said...) The sms doesn't need to know
anything about refcounting or anything special. What does refcounting
give you? I'm still not also sure why locking needs to be in the SMS.
(I think I asked for clarification on this, but I received none...)
All an sms knows how to do is to get a chunk and free a chunk of
memory. None of the pool logic needs to be in sms. I saw that the sms
were just an abstraction around allocating memory. The pool will
actually handle the cleanups. Everyone still uses apr_pool_t. The
pool itself uses apr_sms_t to allocate memory. This enables us to have
a shared memory pool, a file-backed memory pool, a heap-backed memory
pool - whatever we want. The sms doesn't need to do any locking - the
pool will guarantee that the allocation is done atomically by its own
locking mechanisms (what it does now - albeit the pool locking is a bit
coarser than it really needs to be).
I think the thing is that I've seen the sms as slightly different than
what it was originally posted as. So, I might be in the minority here.
I think we are seeing two different views of what an sms should be.
My -1 was non-veto, so it doesn't stop you. It just registers my
dissent. -- justin
Re: cvs commit: apr/threadproc/unix thread.c
Posted by David Reid <dr...@jetnet.co.uk>.
> On Thu, 7 Jun 2001, Sander Striker wrote:
>
> > Argh!!! [getting abit frustrated now, because there seems to be no
> > way of moving forward and thus proving the system]
>
> I think we're at least starting to face the issues head-on. We're making
> progress, believe it or not. =-)
Yes we are!
> > > See, that's where my overall view of "where we hope to get to"
differs.
> > > <shrug> In my mind, APR depends on pools. Period. It would require
a
> > > major overhaul for most APR operations to be safe WITHOUT pools (ie,
lots
> > > of apr_sms_free operations would have to be added, which is exactly
what
> > > the pools are meant to avoid).
> >
> > This is simply not true. Where you pass in pools at the moment you'll
pass
> > in a _tracking_ sms later. This guarantees that stuff is free'd later
on.
>
> Hmm...
>
>
> > > and you get to select where the pool gets its memory from under the
covers
> > > (does it come off the heap, or out of shared memory, or what? The sms
> > > that the pool's based on decides.)
> >
> > What you are basically saying is that you want tracking to be
> > mandatory instead of optional. Why another level of indirection? sms
> > is flexible enough to do what pools can do [apart from an abort
> > function it has almost all the same features. Oh and locking
> > ofcourse...]
>
> Okay, so you've convinced me that it's possible to do. But it's not going
> to happen throughout APR in time for Apache 2.0, I think (I doubt anyone
> here would disagree). So what are the intermediate measures? I'll step
> back now and let you all sort that out.
This is the crux of the issue methinks. We don't yet have a module that
would allow us to even get close to replacing pools. We need a lot of
things from it and Sander and I have had some good early discussions about
how it could work. Basically we want to have a fast, stable tracking
allocator that has a smaller memory footprint than pools. Is it possible?
I don't honestly know but we're going to give it a good try. Why haven't we
opened up our discussions? Because we haven't even got any code and are
still bashing around the early design which is probably better done
privately. Once we have something we like we'll post.
When looking at the code that's there please bear this in mind. The current
apr_sms_tracking module does some of the things that pools do, but it's by
no means a replacement.
The whole structure of the sms code means that we can have a lot of
different methods of allocating/tracking it's memory. the main limit is our
imagination and coding :) Well mainly coding in my case :)
What do we do here and now? Exactly what we've been doing. With the pool
in the sms we have access to all of APR (so it's a better solution than my
original - thanks Greg) which means we can move forward and start developing
some of the things we want and actually code them. The process has revealed
some problems in our assumptions and in some of our code - witness the
changes in locking that I made as a result of trying to get locks into sms -
and so it's a valuable process to go through.
Things on the agenda...
- a "pool replacement" sms module
- shared memory support
- debugging modules (one just to debug and one that dumps memory to files)
To be honest there's enough there to keep us occupied for quite a while to
come. There's also the possibility that we'll arrange some face to face get
togethers to work through some of this, but as Sander, Luke and myself are
in europe they'll be this side of the water, probably in the UK.
> > For people considering -1, please reconsider and cut us some slack so
> > we can at least try and prove our case. If we don't prove anything issue
> > a -1 later and we'll cut the code out [does this sound fair David?]
>
> Okay by me.
OK by me as well, as I think I've shown :)
david
RE: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 7 Jun 2001, Sander Striker wrote:
> Argh!!! [getting abit frustrated now, because there seems to be no
> way of moving forward and thus proving the system]
I think we're at least starting to face the issues head-on. We're making
progress, believe it or not. =-)
> > See, that's where my overall view of "where we hope to get to" differs.
> > <shrug> In my mind, APR depends on pools. Period. It would require a
> > major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> > of apr_sms_free operations would have to be added, which is exactly what
> > the pools are meant to avoid).
>
> This is simply not true. Where you pass in pools at the moment you'll pass
> in a _tracking_ sms later. This guarantees that stuff is free'd later on.
Hmm...
> > and you get to select where the pool gets its memory from under the covers
> > (does it come off the heap, or out of shared memory, or what? The sms
> > that the pool's based on decides.)
>
> What you are basically saying is that you want tracking to be
> mandatory instead of optional. Why another level of indirection? sms
> is flexible enough to do what pools can do [apart from an abort
> function it has almost all the same features. Oh and locking
> ofcourse...]
Okay, so you've convinced me that it's possible to do. But it's not going
to happen throughout APR in time for Apache 2.0, I think (I doubt anyone
here would disagree). So what are the intermediate measures? I'll step
back now and let you all sort that out.
> For people considering -1, please reconsider and cut us some slack so
> we can at least try and prove our case. If we don't prove anything issue
> a -1 later and we'll cut the code out [does this sound fair David?]
Okay by me.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
RE: cvs commit: apr/threadproc/unix thread.c
Posted by Sander Striker <st...@samba-tng.org>.
> On Wed, 6 Jun 2001, David Reid wrote:
>
> > There is no pleasing some people is there??
>
> Nope. =-)
Argh!!! [getting abit frustrated now, because there seems to be no
way of moving forward and thus proving the system]
> > At present pools are a specific implementation of memory management. In
> > time we hope to get sms to a point where we can replace pools
> > with an sms
> > module that is better. When we get there, it won't matter that we have
> > pools in the sms code as when we replace the pools we'll have
> > to go through
> > and change all the apr code.
> >
> > apr_pstrdup(apr_pool_t *pool, char *str)
> > we'll end up with
> > apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
> See, that's where my overall view of "where we hope to get to" differs.
> <shrug> In my mind, APR depends on pools. Period. It would require a
> major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> of apr_sms_free operations would have to be added, which is exactly what
> the pools are meant to avoid).
This is simply not true. Where you pass in pools at the moment you'll pass
in a _tracking_ sms later. This guarantees that stuff is free'd later on.
> So in my mind, you implement pools ON TOP OF sms.
Well, this is not for me to decide, but my personal opinion: yuck!
> That gives you the best of both worlds: you get the convenience of the
> pool API,
Including tracking which you don't need if you have a tracking parent sms
and are only freeing when the parent is freed (ie, a sms associated with
a connection or a request). Also the pool API is a lot less flexible.
> and you get to select where the pool gets its memory from under the covers
> (does it come off the heap, or out of shared memory, or what? The sms
that
> the pool's based on decides.)
What you are basically saying is that you want tracking to be mandatory
instead of optional. Why another level of indirection? sms is flexible
enough
to do what pools can do [apart from an abort function it has almost all the
same features. Oh and locking ofcourse...]
> So you can't do
>
> newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
> because then you have to be sure to
>
> apr_sms_free(str)
>
> because you don't know for sure whether the mem_sys will do it for you or
> not.
Which should be the choice of the user, not for the apr library IMHO.
In other words, it should be up to the user when to free, either through
an apr_sms_destroy() on a tracking sms or through explicit apr_sms_free()
calls.
> So that means you have to keep
>
> newstr = apr_pstrdup(apr_pool_t *pool, char *str)
>
> and change the apr_pool_t struct to include an sms, and to get its memory
> using apr_sms_malloc instead of just plain old malloc.
>
> That's my take on things, anyway.
My fl 0.02 :-)
>
> > As for locking, well the logical level for locking to be
> > implemented is in
> > the sms module. Look at the standard module. malloc should be
> > thread safe
> > so no locking should be required, hence we don't have any. In
> > a tracking system we can't guarantee that so we lock.
To clear this up: this is because we have internal structures in the
tracking sms that are modified when allocing/freeing etc.
> I don't really have a problem with the locking end of things, per se...
> there will probably be some SMS's that need to lock, so we might as well
> give them a convenient means to do so. I think. I haven't really looked
> into this, though.
>
> > So, do I still hear -1's for the pool in sms approach?
>
> I'm not going to say -1... just -0. <shrug>
For people considering -1, please reconsider and cut us some slack so
we can at least try and prove our case. If we don't prove anything issue
a -1 later and we'll cut the code out [does this sound fair David?]
Sander
PS. No, I'm not worked up at the moment and yes my comments are a bit,
what's the word, rigid, but that's just because I'm very tired...
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 6 Jun 2001, David Reid wrote:
> There is no pleasing some people is there??
Nope. =-)
> At present pools are a specific implementation of memory management. In
> time we hope to get sms to a point where we can replace pools with an sms
> module that is better. When we get there, it won't matter that we have
> pools in the sms code as when we replace the pools we'll have to go through
> and change all the apr code.
>
> apr_pstrdup(apr_pool_t *pool, char *str)
> we'll end up with
> apr_pstrdup(apr_sms_t *mem_sys, char *str)
See, that's where my overall view of "where we hope to get to" differs.
<shrug> In my mind, APR depends on pools. Period. It would require a
major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
of apr_sms_free operations would have to be added, which is exactly what
the pools are meant to avoid). So in my mind, you implement pools ON TOP
OF sms. That gives you the best of both worlds: you get the convenience
of the pool API, and you get to select where the pool gets its memory from
under the covers (does it come off the heap, or out of shared memory, or
what? The sms that the pool's based on decides.) So you can't do
newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
because then you have to be sure to
apr_sms_free(str)
because you don't know for sure whether the mem_sys will do it for you or
not. So that means you have to keep
newstr = apr_pstrdup(apr_pool_t *pool, char *str)
and change the apr_pool_t struct to include an sms, and to get its memory
using apr_sms_malloc instead of just plain old malloc.
That's my take on things, anyway.
> As for locking, well the logical level for locking to be implemented is in
> the sms module. Look at the standard module. malloc should be thread safe
> so no locking should be required, hence we don't have any. In a tracking
> system we can't guarantee that so we lock.
I don't really have a problem with the locking end of things, per se...
there will probably be some SMS's that need to lock, so we might as well
give them a convenient means to do so. I think. I haven't really looked
into this, though.
> So, do I still hear -1's for the pool in sms approach?
I'm not going to say -1... just -0. <shrug>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr/threadproc/unix thread.c
Posted by David Reid <dr...@jetnet.co.uk>.
There is no pleasing some people is there??
Here I go with an explanation of why I made the change...
At present pools are a specific implementation of memory management. In
time we hope to get sms to a point where we can replace pools with an sms
module that is better. When we get there, it won't matter that we have
pools in the sms code as when we replace the pools we'll have to go through
and change all the apr code.
So at present have
locks -> apr_pool_t
sms -> locks -> apr_pool_t
When we're done we'll have
locks -> apr_sms_t
sms -> locks -> apr_sms_t
So personally I don't see the problem and thus I made the change! I guess
maybe it's because people keep saying that we're going to change the pools
to use sms. Why? To get the maximum flexibility we'll need to use sms
throughout so while we may have
apr_pstrdup(apr_pool_t *pool, char *str)
we'll end up with
apr_pstrdup(apr_sms_t *mem_sys, char *str)
That's what I'm aiming at and that's why I keep saying that we won't get to
this point until we've released apache. I mean if we had a really kick ass
sms module today that we'd tested to destruction then it'd almost be worth
making the change, but we're not there yet and won't be for a while. When
we do make the change we'll just make an apr_pool_t == apr_sms_t so we ease
the job we'll make for our client apps.
Now that's all in the future and is where I think we'll end up, but until
then we need to be able to use apr from within the memory code. the
addition of a pool isn't a big deal really - view it as another type of
sms - after all it is a memory system isn't it?
We've done it before when we went from context => pool so it's not a huge
problem but we need to wait until a release.
As for locking, well the logical level for locking to be implemented is in
the sms module. Look at the standard module. malloc should be thread safe
so no locking should be required, hence we don't have any. In a tracking
system we can't guarantee that so we lock. In a system that dumps the
memory we'd want to lock around the routine that writes to the file as we
wrote correctly. However, it's really a choice that should be made at sms
level. Does that make more sense? I'm not sure how many modules we'll end
up with and there's nothing to stop platform specific modules being written.
It's even possible we'll have specialist modules for certain specialist
purposes. That's one of the reasons why I still think it'd be interesting
to have dynamic loading of modules so that people can ship binary apache
modules and their own specialist memory modules as well. Just a wild notion
:)
So, do I still hear -1's for the pool in sms approach?
david
> > On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> > > - add an apr_pool_t to the sms structure
> >
> > -1 (non-veto, but awfully close). Uh, why are we doing this?
> > I thought that a pool would be defined in terms of a sms (not now, but
> > at some point). This would not allow that to happen.
> > I'm still not entirely sold on the fact that sms needs locks. I think
> > the locks can be handled at a higher level than sms (i.e. a pool).
>
> I was thinking the exact same thing, actually...
>
> --Cliff
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> > - add an apr_pool_t to the sms structure
>
> -1 (non-veto, but awfully close). Uh, why are we doing this?
> I thought that a pool would be defined in terms of a sms (not now, but
> at some point). This would not allow that to happen.
> I'm still not entirely sold on the fact that sms needs locks. I think
> the locks can be handled at a higher level than sms (i.e. a pool).
I was thinking the exact same thing, actually...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr/threadproc/unix thread.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> - add an apr_pool_t to the sms structure
-1 (non-veto, but awfully close). Uh, why are we doing this?
I thought that a pool would be defined in terms of a sms (not now, but
at some point). This would not allow that to happen.
I'm still not entirely sold on the fact that sms needs locks. I think
the locks can be handled at a higher level than sms (i.e. a pool).
My $.02. -- justin
Re: cvs commit: apr/threadproc/unix thread.c
Posted by David Reid <dr...@jetnet.co.uk>.
Apologies again for this being such a big commit :( I didn't want to commit
stuff before I'd finished, but kept finding more bits I had to do before I
was "finished".
Win32 and OS/2 need the changes I've made to the locking code...
david