That seems reasonable to me. We discovered the problem with mod_jk2.
The code was traversing the pool hierarchy back to the root where they
proceded to create a mutex and set a cleanup. Since the the APR
global_pool is never cleaned up from the root down while APR is in use,
the mutex was allo
Jeff Trawick wrote:
Stas Bekman wrote:
remove:
apr_sockaddr_port_get() - caller can read from sockaddr directly
apr_sockaddr_ip_set() - limitation of IPv4 n.a.s. is bogus
caller should use apr_sockaddr_info_get()
shrug:
apr_sockaddr_port_set() - bad for caller to set i
Mladen Turk wrote:
The fixed patch uses the returning value from apr_thread_cond_timedwait().
Also changed to apr_reslist_timeout_set.
+1...
feel free to nag me off-list tomorrow if nobody has committed it by then and
there are no further objections to resolve
On Tue, 2003-12-09 at 18:43, [EMAIL PROTECTED] wrote:
> bnicholes2003/12/09 09:43:01
>
> Modified:memory/unix apr_pools.c
> Log:
> Since all NetWare memory is shared, allowing an application access to the
> APR global pool allows it to allocate memory and set cleanups that will neve
On Tue, 9 Dec 2003, Mladen Turk wrote:
> That was the bug.
>
> > if not returning whatever apr_thread_cond_timedwait()
> > returned, why not return APR_TIMEUP instead of APR_EAGAIN?
> > but like Cliff said I wonder why the retval of
> > apr_thread_cond_timewait() isn't appropriate?
>
> The fixed p
On Tue, 9 Dec 2003, Jeff Trawick wrote:
> > +if (reslist->timeout) {
> > +if (apr_thread_cond_timedwait(reslist->avail,
> > +reslist->listlock, reslist->timeout) != APR_SUCCESS)
> > +apr_thread_mutex_unlock(reslist->listlock);
> > +
> From: Jeff Trawick
>
> Cliff Woolley wrote:
> >
> > Is it really correct to return APR_EAGAIN regardless of the return
> > value of apr_thread_cond_timedwait()? Or is that a bug caused by a
> > lack of {}'s? This is why we tend to say that you should
> always use
> > {}'s, even if the
>
> Given lack of any other response I bet on the former option too, I went
> the whole hog and removed the file from the build since that was the
> only function in it.
excellent. thanks for following up.
--Geoff
Currently when Apache httpd accepts a new connection via APR, it compares the
fd with FD_SETSIZE and bombs if fd >= FD_SETSIZE.
The limited value of this check is on platforms such as OS X < 10.3 with no
poll(), where APR has to use select(). Unfortunately, use 1K threads with
worker MPM on So
Cliff Woolley wrote:
On Mon, 8 Dec 2003, Mladen Turk wrote:
Can someone review this patch and eventually respond if there are
any chances to get this patch committed to apr-util.
If not we'll make something different then.
+1 (concept)
I think it would have to be called apr_reslist_timeout_set() r
Norman Tuttle wrote:
Jeff:
I think you misunderstood my point here. The preallocation is actually
desirable as it gives the sockets closure relative to pool dynamics. In
simplified English, that means that we can allocate a socket structure
(apr_socket_create), and when we deallocate it,
i.e.,
Stas Bekman wrote:
remove:
apr_sockaddr_port_get() - caller can read from sockaddr directly
apr_sockaddr_ip_set() - limitation of IPv4 n.a.s. is bogus
caller should use apr_sockaddr_info_get()
shrug:
apr_sockaddr_port_set() - bad for caller to set in
On Thu, Dec 04, 2003 at 02:38:27PM -0500, Geoffrey Young wrote:
> hi all...
>
> httpd-2.1 current does not compile cleanly with -Werror (for me at least).
>
> cc1: warnings being treated as errors
> pollacc.c:67: warning: no previous prototype for `apr_socket_from_file'
>
> anyway, it looks like
On Mon, Dec 08, 2003 at 10:27:41PM -0800, Stas Bekman wrote:
> Greg Stein wrote:
> > We can mark them in the 0.9.x branch as deprecated, and we can simply yank
> > them from the 1.0 development line. The whole point of the major version
> > change is to flush out functions like this.
>
> Yes. I wa
Greg Stein wrote:
We can mark them in the 0.9.x branch as deprecated, and we can simply yank
them from the 1.0 development line. The whole point of the major version
change is to flush out functions like this.
Yes. I was pointing out that they aren't marked as deprecated in 0.9.x
Same for apr_poll(
I use apr with httpd 2.0.48, in vc6sp5 debug mode, when thread
die, at ExitThread throws:
Unhandled exception in xxx.exe(MSVCRT.DLL): 0xC005: Access
Violation
But in release mode, no errors. The test code is:
#include "apr_portable.h"
void * __stdcall worker(apr_thread_t
Jeff:
I think you misunderstood my point here. The preallocation is actually
desirable as it gives the sockets closure relative to pool dynamics. In
simplified English, that means that we can allocate a socket structure
(apr_socket_create), and when we deallocate it, all that we need goes
away
We can mark them in the 0.9.x branch as deprecated, and we can simply yank
them from the 1.0 development line. The whole point of the major version
change is to flush out functions like this.
Same for apr_poll() for that matter. It should just go; Justin explained
the reasons/rationale very well.
Greg Stein wrote:
+1 across the board.
On Tue, Dec 02, 2003 at 10:57:24AM -0500, Jeff Trawick wrote:
(or +1, as the case may be)
remove:
apr_sockaddr_port_get() - caller can read from sockaddr directly
apr_sockaddr_ip_set() - limitation of IPv4 n.a.s. is bogus
caller sho
19 matches
Mail list logo