Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Jeff Trawick
Hmmm... A non-threaded app needs to serialize access to a resource across multiple processes. This non-threaded app builds/runs against a threaded APR. Before this patch: we only need one lock on many platforms (app specifies APR_CROSS_PROCESS) After this patch: we need two locks on man

RE: cvs commit: apr/memory/unix apr_sms_trivial.c

2001-07-03 Thread Sander Striker
Thanx Jeff. I must have been real tired last night to miss this stuff. Sorry for the inconvenience. Sander > trawick 01/07/03 05:55:34 > > Modified:memory/unix apr_sms_trivial.c > Log: > apr_sms_trivial_thread_[un]register() got warnings since it was > exported but had no prototy

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Justin Erenkrantz
On Tue, Jul 03, 2001 at 07:05:19AM -0400, Jeff Trawick wrote: > Hmmm... > > A non-threaded app needs to serialize access to a resource across > multiple processes. > > This non-threaded app builds/runs against a threaded APR. Problem right there. You are going to be screwed performance-wise any

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Aaron Bannert
Actually, I don't think an app would ever want to specify CROSS_PROCESS as it is currently implemented, since it is not portable. How would an app developer create a lock that will _never_ serialize in-process threads, and _only_ synchronize across processes? Maybe we're trying to mix too much int

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Aaron Bannert
On Tue, Jul 03, 2001 at 07:55:50AM -0700, Justin Erenkrantz wrote: > Wouldn't it be better to try and determine which platforms/lock types > we don't need the APR_PROCESS_PRIVATE lock on when they attempt to > acquire APR_PROCESS_SHARED? Is there some way to detect that? That is what CROSS_PROC

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Justin Erenkrantz
[ Dropping new-httpd as this has no current relevance to them ] On Tue, Jul 03, 2001 at 09:25:26AM -0700, Aaron Bannert wrote: > That would be useful if APR_HAS_THREADS was somehow set per the app's > definition, not at APR's buildtime. I assume you're talking about this: > > case APR_PROCESS

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Jeff Trawick
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > [ Dropping new-httpd as this has no current relevance to them ] > > On Tue, Jul 03, 2001 at 09:25:26AM -0700, Aaron Bannert wrote: > > That would be useful if APR_HAS_THREADS was somehow set per the app's > > definition, not at APR's buildtime. I as

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Justin Erenkrantz
On Tue, Jul 03, 2001 at 02:46:39PM -0400, Jeff Trawick wrote: > Note that APR currently doesn't have the right information now to set > APR_PROCESS_LOCK_MECH_IS_GLOBAL properly, so we end up getting two > locks instead of one on some platform/mechanisms where it isn't really > needed. > > But assu

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Jeff Trawick
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > > > This could give the non-threaded users of APR even more reason to > > > specify "--without-threads" when configuring - which they should be > > > doing in the first place. > > > > yes. And we want recompiles of APR, no? > > If you have a non-

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Jeff Trawick
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Tue, Jul 03, 2001 at 02:46:39PM -0400, Jeff Trawick wrote: > > Note that APR currently doesn't have the right information now to set > > APR_PROCESS_LOCK_MECH_IS_GLOBAL properly, so we end up getting two > > locks instead of one on some platform/m

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread rbb
> that makes sense to me too for my own purposes, but > > 1) before long I suspect some folks will want/need a single shared >library version of APR which works with multiple APR apps > >and it won't just be "want" because they think it will be nicer to >have one build of APR... it wil

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread Justin Erenkrantz
On Tue, Jul 03, 2001 at 03:02:47PM -0400, Jeff Trawick wrote: > that makes sense to me too for my own purposes, but > > 1) before long I suspect some folks will want/need a single shared >library version of APR which works with multiple APR apps > >and it won't just be "want" because they

Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL

2001-07-03 Thread rbb
> > I'm a bit surprised that none of the folks who were around when > > CROSS_PROCESS vs. LOCKALL was invented have participated in the > > discussion. I think I'm at least as concerned with that as with > > losing a lock flavor. > > I am the person who introduced all of that. To be honest, I ca

[PATCH] fix apr-util/uri

2001-07-03 Thread Joe Orton
A mini-patch to fix 'make -j2' builds in apr-util since the dependency of apr_util.lo on uri_delims.h was missing (it only worked because the targets were ordered correctly): Index: Makefile.in === RCS file: /home/joe/lib/cvsroot/apr-

Re: [PATCH] fix apr-util/uri

2001-07-03 Thread Justin Erenkrantz
On Tue, Jul 03, 2001 at 09:02:49PM +0100, Joe Orton wrote: > A mini-patch to fix 'make -j2' builds in apr-util since the dependency > of apr_util.lo on uri_delims.h was missing (it only worked because the > targets were ordered correctly): Committed. Thanks. We do need the explicit dependency he