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
* server/mpm/worker/worker.c:
(listener_thread): create and add sockets to the pollset using the new
APIs. rearrange the round-robin a little bit to work with the new
pollset return values.
cleaning: get rid of an extraneous status variable. get rid of
obsoleted round-robin code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101801 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
for the Unix MPMs. These have semantics very similar to the
old apachectl commands of the same name.
The use of stderr/stdout and exit status for error conditions
needs to be revisited. For now it matches apachectl behavior.
Justin Erenkrantz got the ball rolling with this feature. Some
of his support code was used unchanged. Other code was shuffled
around and modified or rewritten.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95237 13f79535-47bb-0310-9956-ffa450edef68
threads. We want to get the workers in the pool of available threads ASAP
to keep perform_idle_server_maintenance from thrashing and starting too
many processes prematurely. The code before this patch would dribble workers
into the worker pool over an extended period of time and this prevented
perform_idle_server_maintenance from accurately deciding when new processes
were needed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94889 13f79535-47bb-0310-9956-ffa450edef68
resolve some segfaults see when doing such restarts.
(Justin tweaked the palloc/memset in favor of calloc.)
Submitted by: Aaron Bannert
Reviewed by: Greg Ames, Sander Striker, Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94886 13f79535-47bb-0310-9956-ffa450edef68
ap_queue_info_set_idle() more than once at a time per worker thread.
This fixes an assert coredump.
Submitted by: Aaron Bannert
Reviewed by: Brian Pane
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94840 13f79535-47bb-0310-9956-ffa450edef68
The advantage of doing this is that it enables us to guarantee that the
number of ptrans pools in existence at once is no greater than the
number of worker threads, and that we'll never have to delete ptrans
pools.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94830 13f79535-47bb-0310-9956-ffa450edef68
the listener thread from accept()ing more connections than there are
available workers. This prevents long-running requests from starving
connections that have been accepted but not yet processed.
The queue_info is a simple counter, mutex, and condition variable. Only
the listener thread blocks on the condition, and only when there are no
idle workers. In the fast path there is a mutex lock, integer decrement,
and and unlock (among a few conditionals). The worker threads each notify
the queue_info when they are about to block on the normal worker_queue
waiting for some connection to process, which wakes up any sleeping
listener thread to go perform another accept() in parallel.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94824 13f79535-47bb-0310-9956-ffa450edef68
the parent process to run in the foreground
(NO_DETACH is a special mode for running under
programs like daemontools)
the existing flag -DDEBUG turns on FOREGROUND
now instead of NO_DETACH
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94441 13f79535-47bb-0310-9956-ffa450edef68
Don't create a listener thread until we have a worker thread. Otherwise,
in situations where we'll have to wait a while to take over scoreboard
slots from a previous generation, we'll be accepting connections we can't
process yet.
Don't let the listener thread clobber the scoreboard entry of the first
worker thread.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94420 13f79535-47bb-0310-9956-ffa450edef68
and completely contained in a file (SCOREBOARD_FILE) has been
removed. This does not affect scoreboards which are *mapped* to
files using named-shared-memory at all. This implies that scoreboards
must be based, at some level, on native shared memory (mmap, shm_open,
shmget, whatever), but the code has assumed that for quite awhile
now. Having the scoreboard be *based* on a file makes no sense today.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94306 13f79535-47bb-0310-9956-ffa450edef68
Add an allocator-passing mechanism throughout the bucket brigades API.
From Apache's standpoint, the apr_bucket_alloc_t* used throughout a given
connection is stored in the conn_rec by the create_connection hook. That
means it's the MPM's job to optimize recycling of apr_bucket_alloc_t's --
the MPM must ensure that no two threads can ever use the same one at the
same time, for instance.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94304 13f79535-47bb-0310-9956-ffa450edef68
get MaxRequestsPerChild to work again by allowing the main thread of
a child to be interrupted by one of the other threads in the process
this should get graceful termination to work after encountering one of
the various possible error conditions in the listener and worker threads
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94232 13f79535-47bb-0310-9956-ffa450edef68
threads could exit even though there were connections waiting in the
queue.
Now, for a graceful restart the worker threads won't exit until they
are told that the queue has been drained and no more connections will
ever be added.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94106 13f79535-47bb-0310-9956-ffa450edef68
go away before the workers... introduce separate XXX_may_exit flags
for our different categories of threads so that a future fix for
graceful shutdown can terminate them in the right order
rename signal_workers() to signal_threads() and give it a parameter
so it knows whether or not termination should be graceful
this commit doesn't change the behavior in any noticeable way; the
flags used to tell threads to go away are still set at about the same
time
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94095 13f79535-47bb-0310-9956-ffa450edef68
