Would it make more sense to have something that would be more
specific to each lock type (mutex, semaphore, read/write locks)?
You tell me :)
I find the whole notion of needing to tell APR which mechanism to use
fairly klunky, and OS-specific stuff like this really klunky. Given
that
[EMAIL PROTECTED] writes:
Would it make more sense to have something that would be more
specific to each lock type (mutex, semaphore, read/write locks)?
You tell me :)
I find the whole notion of needing to tell APR which mechanism to use
fairly klunky, and OS-specific stuff like
On Mon, Jun 25, 2001 at 07:30:51PM -0400, Jeff Trawick wrote:
Here's an idea:
Leave apr_lock_create() alone (though I think some other folks wanna
muck with it :) ).
Add apr_lock_create_np() (or some gstein-approved name) which
1) has the OS-specific details specified in enum parameters
On 25 Jun 2001, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
Would it make more sense to have something that would be more
specific to each lock type (mutex, semaphore, read/write locks)?
You tell me :)
I find the whole notion of needing to tell APR which mechanism to use
Hi All,
sorry to rekindle this fire, but I want to get this settled and move on.
In my previous posts I said that I do not see why there are both
APR_CROSS_PROCESS and APR_LOCK_ALL semantics in APR's lock
routines. Instead I'd like to see APR_LOCK_ALL go away, and
APR_CROSS_PROCESS to provide
On Sun, Jun 24, 2001 at 10:30:00AM -0700, Justin Erenkrantz wrote:
On Sun, Jun 24, 2001 at 07:18:41PM +0200, Luke Kenneth Casson Leighton wrote:
I'd guess that it wouldn't be too hard on your end to at
least post a patch/code (within APR framework) that illustrates what
you are talking
On Tue, 26 Jun 2001, Greg Stein wrote:
The setaside() could be called on *really* large files. Calling mmap could
be a very bad thing. Just dup the FILE bucket and leave it at that. The
decision to do the mmap can/should come when it becomes necessary.
Okay, I'll change file_setaside() so
PS: I still question the copying of the mmap data into the pool in
pool_setaside()... it seems to me that it's easy for that to accidentally
copy a very large file in its entirety into memory. What am I missing?
Your right, this can do that. However, we really can't keep that from
On Tue, Jun 26, 2001 at 11:29:32AM -0400, Cliff Woolley wrote:
On Tue, 26 Jun 2001, Justin Erenkrantz wrote:
Why? Don't we need to create a duplicate file handle? What am I
missing? -- justin
Not for file_setaside() we don't. All file_setaside() cares about is that
the apr_file_t
On Tue, 26 Jun 2001, Cliff Woolley wrote:
Your right, this can do that. However, we really can't keep that from
happening. In reality, the mmap_setaside function should just map it back
to a file opened out of the new pool.
I see now that by map it back to a file you meant reopen the
Instead of creating a new mmap, how about using the same one
and adding a reference count?
--Brian
Cliff Woolley wrote:
On Tue, 26 Jun 2001, Cliff Woolley wrote:
Your right, this can do that. However, we really can't keep that from
happening. In reality, the mmap_setaside function should just
At 12:05 PM 06/26/2001, Cliff Woolley wrote:
Obviously I was missing the same thing as I was missing on the
file_cleanup() thing, which is the simple fact that the original MMAP
might get deleted by the pool cleanup on the old pool. I don't know
where
my brain is today.
Anyway, the problem is
At 12:53 PM 06/26/2001, Greg Marr wrote:
At 12:05 PM 06/26/2001, Cliff Woolley wrote:
Anyway, the problem is not 100% solved. We need to make ourselves
a new
MMAP to the file that we know won't get deleted.
Why not simply reference count the MMAP/file handle?
I came up with these questions after
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
I came up with these questions after sending this suggestion:
Where would the reference count go?
- Instead of having an MMAP/file handle, the apr_*_t would have to
point to a structure containing the MMAP/file handle, and a reference
count. This memory for this structure could not
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
19 matches
Mail list logo
