Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Paul Querna [EMAIL PROTECTED] wrote on 2008-9-21 4:21 Graham Leggett wrote: I know there are likely huge problems with this, but I would like to see how far we can push the Event MPM, figure out what to do better, if there is anything, and then really dive into the 3.0 development before ApacheCon. How difficult would this be to support in the other MPMs? Windows, Worker MPM and the similar threaded MPMs could do it easily. But, IMO, I want to eliminate all of the MPMs for 2.4/3.0. I believe the MPMs as they are designed right now, are both a layer of portability, and a module that defines behavior or the model. ... Basically, one MPM to rule them all, with a configuration directive that can make it act like prefork or the event MPMs. Currently the role that MPMs play is to map a connection (with many requests, by HTTP/1.1) to a worker (a thread or process). But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). Such a layer should unify the upper interface of Event driven i/o, Windows i/o completion port, and many other async i/o mechanisms. With luck and careful design, the current filtered i/o chain and the module API can remain the same. I hope that this would be one of the best features that 2.4+ will bring to us, as finally it will support any optimal i/o model on various platforms, and answer the doubts on Apache performance once and forever. Bing School of EE CS, Peking University, Beijing 100871
Re: [flood] Critical section for flood_report_relative_times.c
On Tue, Sep 16, 2008 at 9:45 PM, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Wed, Sep 3, 2008 at 2:28 AM, Ohad Lutzky [EMAIL PROTECTED] wrote: From flood_report_relative_times.c (SVN): /* FIXME: this call may need to be in a critical section */ #if APR_HAS_THREADS apr_file_printf(local_stdout, %s %ld %s\n, buf, apr_os_thread_current(), req-uri); #else apr_file_printf(local_stdout, %s %d %s\n, buf, getpid(), req-uri); #endif The comment is right - it does need to be in a critical section. For the case of multiple processes, flock can be used. However, for the case of a single process, this doesn't work, and a mutex would be in order. What would be the correct way to go about organizing such a per-process mutex? Note that apr_file_printf indirectly calls apr_file_write, which is thread-safe - however, it call it multiple times, which can (and does) lead to interlacing in output. Yup, I've seen that before, but I generally tend to ignore it. =) I believe the best way would be to add a mutex in the config_t structure and lock that in the report function. Rough patch below. What do you think? -- justin Index: flood_farm.c === --- flood_farm.c(revision 695997) +++ flood_farm.c(working copy) *SNIP* patch *SNIP* The patch seems to work well, thanks! :) -- Man is the only animal that laughs and weeps, for he is the only animal that is struck with the difference between what things are and what they ought to be. - William Hazlitt Ohad Lutzky
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
On Sep 20, 2008, at 4:31 PM, Paul Querna wrote: Jim Jagielski wrote: On Sat, Sep 20, 2008 at 11:58:09AM -, [EMAIL PROTECTED] wrote: -#define ap_queue_empty(queue) ((queue)-nelts == 0) +#define ap_queue_empty(queue) ((queue)-nelts == 0 APR_RING_EMPTY(queue-timers ,timer_event_t, link)) Not || ? Don't think so? You want to return true if there are both zero entries in the array, and zero in the ring. And false if either has something in it. Ahhh yes, we need to check both structs in the queue now.
