damn meetings... the code is 90% there and lives in:
http://webperf.org/a2/pool/
the code is designed to test 'pools' so SMS would have to implement
the pool function names... (for the first pass of the code anyway)
..Ian
(hoping to complete it tomorrow)
On 28 Jun 2001 08:51:00 -0700, Justi
David Reid wrote:
AFAICT there's no way to
figure out how to set the gmt offset on Solaris when passing in a value,
After two minutes of manpage reading and one minute of coding:
#include
#include
int main (void)
{
time_t t1, t2;
struct tm tm;
t1 = time(0);
> >I guess a thread that registers its interest in a child SMS is by
> >definition 'interested' in all ancestors of that SMS...
Yes, exactly right :)
> The more I think about it, the trickier the "register interest" paradigm
> looks. The implementation is straightforward: each SMS with children
Cliff Woolley wrote:
On Thu, 28 Jun 2001, Brian Pane wrote:
I like the concept of registering threads' "interest" in an sms. But how do
you handle the need for synchronization in a parent sms? E.g., if an app
creates an global sms and then two different threads create sms_block
instances with the
Hi Ian,
> I'm in the middle of writing a pool-tester
> which can take a file and pool allocation commands
> (alloc/create/destroy/etc)
> and replay them.
> combine this with some threads, and a capture tool in the current pool
> code and we should be able to test different pooling algorithms easil
> On Thu, Jun 28, 2001 at 08:28:41AM -0700, Ian Holsman wrote:
> > I'm in the middle of writing a pool-tester
> > which can take a file and pool allocation commands
> > (alloc/create/destroy/etc)
> > and replay them.
> > combine this with some threads, and a capture tool in the current pool
> > cod
David Reid wrote:
OK, basically apr_implode_time ONLY works with an apr_exploded_time_t. We
have a number of ways of getting one of those,
/**
* convert a time to its human readable components using an offset
* from GMT
* @param result the exploded time
* @param input the time to explode
* @param
On Thu, 28 Jun 2001, Brian Pane wrote:
> I like the concept of registering threads' "interest" in an sms. But how do
> you handle the need for synchronization in a parent sms? E.g., if an app
> creates an global sms and then two different threads create sms_block
> instances with the first sms a
David Reid wrote:
OK, well I'll try to add some stuff to this discussion...
Last night I tried to get sms looking and acting as pools Basically I added
some stuff and munged my tree so that when apr_pool calls were made they
were answered in sms code. This is configurable via an --enable-sms swit
Bill Stoddard wrote:
> I have expressed my distaste for the "one mutex fits all" approach of APR for
> quite a
> while. +1
>
I'm thinking that one I implement the 2.0 version, it makes sense for
the 1.3 tree as well (I know, feature creep). But it's also much easier
under 1.3 :)
--
===
OK, well I'll try to add some stuff to this discussion...
Last night I tried to get sms looking and acting as pools Basically I added
some stuff and munged my tree so that when apr_pool calls were made they
were answered in sms code. This is configurable via an --enable-sms switch
to configure.
I've reviewed the code and can't quite see what you mean...
> >I believe this is a bug. However, we have never been able to reliably
fix
> >it. You should check the APR list archives, because David Reid and I
> >discussed this a while back. It was probably around March of this year.
Read on...
On Thu, Jun 28, 2001 at 08:28:41AM -0700, Ian Holsman wrote:
> I'm in the middle of writing a pool-tester
> which can take a file and pool allocation commands
> (alloc/create/destroy/etc)
> and replay them.
> combine this with some threads, and a capture tool in the current pool
> code and we shoul
On 27 Jun 2001 22:32:24 -0700, Justin Erenkrantz wrote:
> On Wed, Jun 27, 2001 at 07:46:25PM -0700, Brian Pane wrote:
> > Assuming that fixing it with code would mean adding a lock around
> > that block in apr_palloc, I submit that fixing it with documentation
> > is the better option. Given how m
On Mon, Jun 25, 2001 at 12:54:26PM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
> > above were to say, well, if you have the same names, but
> > different functionality, why would you want to limit
> > the [apr] functionality to that of the least-fu
Ryan and I did discuss this but I think it was face to face at Santa Clara
when I made some big changes to that code to get it working :) I'll have a
look at the code and see what's going on, but we should be using the offset
if there is one, or at least so I believe without reviewing the code.
d
On Wed, Jun 27, 2001 at 10:17:40PM -0700, [EMAIL PROTECTED] wrote:
>
> Not to be contrary, but this can be easily resolved, by passing in a
> simple flag when creating a pool. That flag tells us whether or not we
> should lock when using the pool.
The real point is that we have a global freelist
On Wed, Jun 27, 2001 at 07:46:25PM -0700, Brian Pane wrote:
> Assuming that fixing it with code would mean adding a lock around
> that block in apr_palloc, I submit that fixing it with documentation
> is the better option. Given how much slower the threaded MPM is
> than the prefork one right now,
Not to be contrary, but this can be easily resolved, by passing in a
simple flag when creating a pool. That flag tells us whether or not we
should lock when using the pool.
Ryan
On 28 Jun 2001 [EMAIL PROTECTED] wrote:
> jerenkrantz01/06/27 22:14:30
>
> Modified:.STATUS
> Lo
[EMAIL PROTECTED] wrote:
I believe this is a bug. However, we have never been able to reliably fix
it. You should check the APR list archives, because David Reid and I
discussed this a while back. It was probably around March of this year.
Hmm. Couldn't find anything there ...
You could also che
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/06/27 21:07:15 $]
Release:
2.0a9 : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Need apu_compat.h to track the latest renames
Status: someone want to step up to diff na
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/06/05 07:56:08 $]
Release:
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2
I believe this is a bug. However, we have never been able to reliably fix
it. You should check the APR list archives, because David Reid and I
discussed this a while back. It was probably around March of this year.
You could also check CVS for the logs for the time code on Unix. That
would giv
Right now, the Unix version of apr_implode_time completely ignores the
tm_gmtoff field and does not adjust for the time zone.. This means that
imploding an apr_time_t with a non-zero tm_gmtoffset will *not* yield a
correct time value.
My first reaction upon noticing this was to simply go and fi
Assuming that fixing it with code would mean adding a lock around
that block in apr_palloc, I submit that fixing it with documentation
is the better option. Given how much slower the threaded MPM is
than the prefork one right now, I think that adding more mutex overhead
would be bad. :-(
--Brian
[
25 matches
Mail list logo
