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
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
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
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
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
[ 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
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
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
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-
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
> 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
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
> > 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
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-
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
15 matches
Mail list logo