[EMAIL PROTECTED] wrote:
>
> jwoolley02/04/18 23:07:50
>
> Modified:buckets apr_buckets_mmap.c
> Log:
> Fix the mmap cleanup problem seen on daedalus.
:-) :-)
I missed most of the discussion on this due to e-mail problems. Dang, I'm sure
glad I didn't have to debug this one.
On Tue, 26 Jun 2001, Greg Marr wrote:
> At 03:19 PM 06/26/2001, [EMAIL PROTECTED] wrote:
> >No. You can't allocate the MMAP out of malloc. One of the goals of
> >pools is that they allow us to call malloc as little as
> >possible. The MMAP should just get a copy of the filename, and this
> >pro
At 03:19 PM 06/26/2001, [EMAIL PROTECTED] wrote:
No. You can't allocate the MMAP out of malloc. One of the goals of
pools is that they allow us to call malloc as little as
possible. The MMAP should just get a copy of the filename, and this
problem goes away.
You'd rather allocate and copy a s
> > 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 structur
On Tue, 26 Jun 2001, Greg Marr wrote:
> >Why not simply reference count the MMAP/file handle?
>
> 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 cont
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
On Tue, 26 Jun 2001, Brian Pane wrote:
> Instead of creating a new mmap, how about using the same one
> and adding a reference count?
That's exactly what I've been thinking... I haven't figured out the
details of what's involved yet and if that means we'll shoot ourselves in
the foot in some othe
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 no
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 map
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
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.
>
> Hmmm... why's that? Once the file is MMAPed, you don't
On Tue, 26 Jun 2001 [EMAIL PROTECTED] 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.
Hmmm... why's that? Once the file is MMAPed, you don't even n
> 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
h
On Tue, Jun 26, 2001 at 03:20:33AM -, [EMAIL PROTECTED] wrote:
> jwoolley01/06/25 20:20:32
>
> Modified:buckets apr_buckets_mmap.c
> Log:
> Get the prototype for memcpy().
>
> PS: I still question the copying of the mmap data into the pool in
> pool_setaside()... it seems
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
> pass the right value to free() to prevent segfaults and corrupted
> heaps and other nasties
Ugghghhh... damn me. I'm just causing all sorts of problems, aren't I?
--Cliff
15 matches
Mail list logo
