to override default thread stack size for threads which handle
client connections. Required for some third-party modules on
platforms with small default thread stack size.
This is also useful for trimming back the stack size on
platforms with relatively large default stack size in order to
conserve address space for supporting more threads per child.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@102931 13f79535-47bb-0310-9956-ffa450edef68
is at least FD_SETSIZE.
That isn't a problem for most users (since poll() is widespread).
On old boxes where select() must be used by APR, APR needs to fail
operations that don't work with such fds.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@102419 13f79535-47bb-0310-9956-ffa450edef68
when necessary. Which is to say that it's necessary in all cases except
for prefork, where the change to apr-util to have it use the allocator
from the pool passed in is already sufficient.
Reviewed by: Jean-Jacques Clar, Sander Striker, Brad Nicholes
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101122 13f79535-47bb-0310-9956-ffa450edef68
a note on perchild:
perchild exception handling was busted before this and is still busted
the problem I noticed was that a client that exposes a segfault never
gets its connection dropped and the parent never notices that the
child process that segfaulted hasexited
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99312 13f79535-47bb-0310-9956-ffa450edef68
optimal, because it still uses the compatibility functions to make it
work, but it does work. The next step will be to take the memory for
the pollsets under Apache's control.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96005 13f79535-47bb-0310-9956-ffa450edef68
to configure the maximum amount of memory the allocators will
hold on to for reuse. Anything over the MaxMemFree threshold
will be free()d. This directive is usefull when uncommon large
peaks occur in memory usage. It should _not_ be used to mask
defective modules' memory use.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95954 13f79535-47bb-0310-9956-ffa450edef68
startup message regarding AcceptMutex (what we are using and what
the default is) "fully" match what is present in 1.3.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95568 13f79535-47bb-0310-9956-ffa450edef68
- Add a "state" variable to the worker_wakeup_info struct. This is
used to make sure that we act on the correct signal, and to know when
to shut down a worker thread.
- Fix the call when the worker thread waits for a connection to use
the new state variable and use mutexes around the cond_wait() call.
- Change the interrupt_all() call to set the WORKER_TERMINATED state.
- Add two AP_DEBUG_ASSERT() to make sure that we aren't waking up
a worker thread before it is idle.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94843 13f79535-47bb-0310-9956-ffa450edef68
- We don't need the listener_blocked flag, just check if the element
we're adding makes the stack non-empty.
- When we are terminated, return APR_EOF; catch this event in the
worker thread and the listener thread.
- When shutting down, always signal a potential listener thread.
- Wait to signal the listener thread until after we add the worker
element to the stack.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94841 13f79535-47bb-0310-9956-ffa450edef68
The threadpool MPM implements Aaron Bannert's "time-space tradeoff"
design managing idle workers. Rather than putting accepted connections
into a queue, the threadpool MPM keeps idle worker threads in a stack.
Its dedicated listener thread retrieves an idle worker from the stack
before accepting a connection. If there are no idle workers, the
listener blocks until a worker becomes available before doing an accept.
In many ways, threadpool is also a variant of leader/follower. They
both maintain a stack of idle threads. The difference is that threadpool
has a dedicated listener thread, and leader/follower rotates the listening
responsibility among its worker threads. In my initial testing, the
leader/follower MPM performs very well on multiprocessor Solaris 8 when
listening on a single port, but poorly when listening on multiple ports.
(I don't know why this is happening. What I've found so far is that
when you add a poll on the listen socket(s) before the accept in the
leader/follower MPM, all the socket-related syscalls in the httpd get
slower. My hypothesis is that the thread scheduler is making an optimal
decision about where (on what CPU) to run the newly awakened thread if
its first syscall is an accept, and a nonoptimal decision if its first
syscall is a poll.) The threadpool MPM performs better with multiple
listener ports, and in my testing so far it looks competitive with
leader/follower when running with a single listener.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94672 13f79535-47bb-0310-9956-ffa450edef68
