> Correct, but wouldn't it be "fairly" expensive to calculate how much
> space you have allocated with MMAP? Or, you try and keep a static
> "cached" value of how much space you've allocated. I bet this might be
> a good place to use a reader/writer lock (wonder if anyone has
> implemented tha
On Mon, Apr 30, 2001 at 05:58:30PM -0400, Jeff Trawick wrote:
> Jon Travis <[EMAIL PROTECTED]> writes:
>
> > I need a routine to fetch the socket family. I could just refer
> > to the information in the sockaddr_t address length, but that is
> > rather hackish. Anyway, here tis. We should also
On Mon, Apr 30, 2001 at 03:20:17PM -0400, Cliff Woolley wrote:
> > How do we decide that? Doesn't that depend on your OS and the size of
> > the MMAP extents (imagine 2 2GB files in your cache - which may be fine
> > on certain OSes but not on others - imagine 64bit address spaces). That
> > is m
On Mon, Apr 30, 2001 at 03:11:29PM -0400, Christian Gross wrote:
> Right now it is this.
>
> struct apr_lock_t {
> apr_pool_t *cntxt;
> apr_locktype_e type;
> apr_lockscope_e scope;
> HANDLE mutex;
> CRITICAL_SECTION section;
> char *fname;
> };
>
> Would it not be better
[EMAIL PROTECTED] writes:
> I personally like Jeff's patch, with one minor adjustment.
>
> I would do something like the following
>
> #ifndef HAVE_SET_H_ERRNO
> #define set_h_errno(val) h_errno = val
> #endif
>
> And then always use set_h_errno. However, that is just my personal
> preferenc
Jon Travis <[EMAIL PROTECTED]> writes:
> I need a routine to fetch the socket family. I could just refer
> to the information in the sockaddr_t address length, but that is
> rather hackish. Anyway, here tis. We should also probably be
> moving towards making the sockaddr_t an opaque type, or at
> Note that this path is only used on systems with getnameinfo() and IPv6
> support. The h_errno kludge helps out with some getnameinfo() issues
> on common versions of glibc. Before we truly clean up this code we
> need to understand what is needed to operate with getnameinfo() across
> a variet
On Mon, 30 Apr 2001, Cliff Woolley wrote:
> This is definitely better than the leak. =-) And nothing says that the
> cache can't apr_mmap_delete() the MMAP associated with the master file
> bucket as long as refcount==1 (ie, there are no requests using that
> file/mmap currently in progress) if
On Mon, 30 Apr 2001 12:31:27 -0400, you wrote:
>This looks wrong. An APR_INTRAPROCESS lock should use a critical section, not
>a mutex.
Ooops...
Now I remember why I also use Mutexes. Mutexes can be signaled and
with the reader writer code I need to be able to signal a single
blocked writer
[Forgive me, Bill & Justin, for redirecting my answers to your questions
back to the list... it's just that the questions are very good ones
and others might be wondering the same things or have other opinions
on the matter.]
On Mon, 30 Apr 2001, Justin Erenkrantz wrote:
> On Mon,
On Mon, 30 Apr 2001, Bill Stoddard wrote:
> > the next time they're read. But the master copy in the cache will never
> > BE read! So the copy in the cache always remains of file type, not mmap
> > type, and copies of the master made to serve future requests will start
> > out as file type as we
Jeff and I talked about this when we added the IPv6 stuff (which included
the sockaddr types) and Jeff's feeling was to leave these functions and let
people access the details directly. I don't mind either approach...
david
- Original Message -
From: "Jon Travis" <[EMAIL PROTECTED]>
To:
I need a routine to fetch the socket family. I could just refer
to the information in the sockaddr_t address length, but that is
rather hackish. Anyway, here tis. We should also probably be
moving towards making the sockaddr_t an opaque type, or at least
some of the members.
Index: include/apr
That is what I thought.
I can change the code, but to be honest I do prefer Mutexes...
The lock contention speed slow down is something that I seen Richter
talk about.
Christian
On Mon, 30 Apr 2001 13:05:02 -0400, you wrote:
>The peformance numbers I have seen indicate that a critical section
On Mon, 30 Apr 2001, Bill Stoddard wrote:
> I lost the original context for this discussion... Exactly when will a
> file bucket morph to an MMAP bucket? My concern is not to break using
> apr_sendfile(), which on some OSes can provide a big performance
> boost.
I thought about that, and it is a
On Mon, 30 Apr 2001 12:31:27 -0400, you wrote:
>
>This looks wrong. An APR_INTRAPROCESS lock should use a critical section, not
>a mutex.
>
I was wondering about this. How come the use of a critical section?
The only advantage that critical section offers is speed. But even
that is debatable.
Christian,
I have not looked at this patch in excruciating detail but...
> Hi
>
> Here is the second iteration of the RW lock code for the Windows. It
> includes the fix for the cross-process RW lock.
>
> Christian
>
>
> +if (newlock->type == APR_MUTEX) {
> +newlock->blockedR
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 9:46 AM
> Help me out here... I don't follow your comments.
>
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > Jeff,
> >
> > this is the wrong solution (and it was anticipated). Since win32 and OS2
> > don't
>
hi.
you seemed to have missed the change in sdbm_private.h
\
cvs server: Diffing .
Index: sdbm_private.h
===
RCS file: /home/cvspublic/apr-util/dbm/sdbm/sdbm_private.h,v
retrieving revision 1.3
diff -u -r1.3 sdbm_private.h
--- sdbm_pr
On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote:
>
> I personally like Jeff's patch, with one minor adjustment.
>
> I would do something like the following
>
> #ifndef HAVE_SET_H_ERRNO
> #define set_h_errno(val) h_errno = val
> #endif
>
> And then always use set_h_errno. However, that is just my pe
I personally like Jeff's patch, with one minor adjustment.
I would do something like the following
#ifndef HAVE_SET_H_ERRNO
#define set_h_errno(val) h_errno = val
#endif
And then always use set_h_errno. However, that is just my personal
preference for keeping ifdefs out of the code. Other t
Help me out here... I don't follow your comments.
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> Jeff,
>
> this is the wrong solution (and it was anticipated). Since win32 and OS2
> don't
> need the unix MPM's they were never fixed, apparently (from this
> report) they must be.
what i
On Sun, 29 Apr 2001, Roy T. Fielding wrote:
> > Back out the last change to the Makefile in the test directory. Those
> > changes broke the build in that directory. By backing them out, we can
> > continue to build the test programs.
>
> Backing the changes out is fine, but those programs
Jeff,
this is the wrong solution (and it was anticipated). Since win32 and OS2
don't
need the unix MPM's they were never fixed, apparently (from this report) they
must be.
We can't go munging system symbols, see the declarations in apr_errno.h for
the
apr_get_netos_error() (and if we need
> Back out the last change to the Makefile in the test directory. Those
> changes broke the build in that directory. By backing them out, we can
> continue to build the test programs.
Backing the changes out is fine, but those programs don't build now either.
They haven't been buildable si
25 matches
Mail list logo
