On 28 Jun 2001 15:56:06 -0700, Ian Holsman wrote:
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
I wrote:
For now, I'll hack together a spin lock prototype to see if it yields any
measurable improvement in httpd speed.
This is now done, and the short answer is that using a custom
spin lock implementation in place of pthread mutexes in the
pool allocator code doesn't measurably improve the
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 much
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 should be
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.
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
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
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 easily.
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
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
just
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,
[...]
In the current apr_palloc, the lock is only around the call to new_block.
I think that's reasonable; new_block is manipulating a global
free list, so it has to be mutex-protected.
This triggered me to investigate the pools code again. It seems to me that
there is a possible race
Yes, there's definitely a race condition there. I noticed that
too, and I thought it was intentional (i.e., that the lack of a
lock was a conscious choice to avoid a performance penalty
for apps in which pools aren't shared across threads) and
harmless (because there aren't any pools in Apache
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as a complement to the
current intraprocess locks in APR. There are some places, like
the pool memory allocator, where a spinlock
On Tue, Jun 26, 2001 at 10:49:42AM -0700, Brian Pane wrote:
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as a complement to the
current intraprocess locks in APR. There
Justin Erenkrantz wrote:
On Tue, Jun 26, 2001 at 10:49:42AM -0700, Brian Pane wrote:
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as a complement to the
current intraprocess
On Tue, Jun 26, 2001 at 11:24:25AM -0700, Brian Pane wrote:
I'm all in favor of getting rid of the mutexes in the pool allocator code
where possible. I think locking is inevitable, though, in order to handle
the allocation of new blocks for a pool--which seems to be where most
of the mutex
For now, I'll hack together a spin lock prototype to see if it
yields any
measurable improvement in httpd speed.
--Brian
Isn't this simillar to the work being done with SMS and the SMS
allocater and the SMS trivial thing mentioned a while ago?
if we can removed the
18 matches
Mail list logo
