Re: Comments on accept-mutex/single-listen patch ??
Peace! I'll commit minus SingleListen :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: Comments on accept-mutex/single-listen patch ??
On Wed, 29 Aug 2001, Jim Jagielski wrote: Jeff Trawick wrote: how would it not work? fubar kernel? The trick would be in it *working*... NONE implies no mutexing at all, even for multiple listeners. And *that's* the exception. In some environments - for example with a clever linux or freebsd kernel it may may perfect sense - i.e. if you can be sure that the kernel has enough (filtering/sense) to take care of this. But yes - do this in the wrong environment and you shoot yourself in the foot. But then again pick the wrong Accept method and you do the same ! Dw
Re: Comments on accept-mutex/single-listen patch ??
On Wed, 29 Aug 2001, Marc Slemko wrote: On Wed, 29 Aug 2001, Jim Jagielski wrote: Marc Slemko wrote: So I don't see how NONE is viable on _ANY_ platform in the multiple listener case. It may seem to mostly work, but it is not reliable and can not be permitted. threaded ??? First off, simply being threaded doesn't avoid the issue... it depends on the particular model being used (ie. the MPM in 2.x...). FreeBSD with clever enough kernel hacking. Just have a look at the http filtering in freebsd for some fun. I am sure someone could do the same with linux. Dw
Re: Comments on accept-mutex/single-listen patch ??
Jim Jagielski [EMAIL PROTECTED] writes: At 11:00 AM -0400 8/28/01, Jeff Trawick wrote: HAVE_NONE_xxx means that you can turn the accept mutex into a no-op, even in the multiple-listener case. If we can play around with this on one platform (e.g., Darwin), why can't we play around with this everywhere? Because, at least with the systems I've been testing, it appears to work OK on OS X, and, as such, we should allow others to have the choice. I've no idea if it works under IRIX, and having it as a compiled default implies that we've tested it as such... Basically, I want people to be able to use any of the compiled-in methods and have Apache work (maybe not the fastest, but at least we know it works). If we find out that NONE is supported and viable on other platforms, we'll change things to make it a compiled default, but it's premature to do it *now* without that knowledge. how would it not work? fubar kernel? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
On Wed, 29 Aug 2001, Jim Jagielski wrote: recall that the current code *defaults* to NONE (basically, if no other method is compiled in) and will allow that option to be used (but will post a warning unless MULTITHREAD is defined). So we're even *safer* than the current such that if none are compiled in, we don't start. The reason the current 1.3 non-MULTITHREAD code complains if it doesn't know what method works for serialized accepts is because they are _REQUIRED_ for things to work properly. Not having them is an indication that the port does not work correctly. Basically the patch creates a set method based on that, and *allows* it to be compiled in if desired. Nothing more. I'd like more people to test the OS X implementation out, because that's the only one so far that I've seen that appears to work with some limited stress testing. And if we remove that from the Darwin case, so be it. There is nothing to test. Using the 1.3 process based model, you need serialized accepts if you have multiple listening sockets. Period. Adding an option to disable that simply doesn't make any sense. appears to work is irrelevant when you are dealing with race conditions. We went through all the reasons why it is needed when it was added in the first place, it wasn't just added on a whim. What your patch does is make it appear legitimate to not use any accept mutex in the multiple listener case on some non-MULTITHREAD platforms on 1.3. That is not right.
Re: Comments on accept-mutex/single-listen patch ??
At 11:00 AM -0400 8/28/01, Jeff Trawick wrote: The order it checks for (at the moment :) ) is sysvsem, flock, pthread mutex, fcntl. The last match wins (i.e., fcntl is preferred). This can be overridden on a platform basis in apr_hints.m4 by setting the variable apr_lock_method. That's cool. why is SingleListen needed? Pretty much to make SINGLE_LISTEN runtime rather than compile time... Again, to give the admins more control over how Apache handles mutexing. I'm not totally against it, it just seems that it is for playing around (sort of like USE_NONE_SERIALIZED_ACCEPT) or trying to work around an Apache bug (i.e., maybe there is some platform/version where we're supposed to turn on SINGLE_LISTEN_UNSERIALIZE_ACCEPT but don't). Why can't they compile this in? This would seem to be useful in extremely rare circumstances, and only for somebody who really knows what they are doing. Agreed... But there have been times when, as an admin, I wished that I had the capability... I still don't grok why SingleListen is needed. In fact, it seems down right dangerous and I am -1 on this directive until someone bashes me with a clue stick :-) Does everyone understand the S_L_U_A optimization? Apache httpd must call accept() to pick up inbound connections. Apache httpd runs with multiple threads/processes that all call accept() to pick up connections. The issue is this: do we allow all the threads/processes to all call/block in the accept() waiting for connections? The answer depends on the capabilities of the OS, specifically how accept() is implemented in the OS. I know of at least two problems with allowing multiple threads/processes to block in accept(): 1. thundering herd This is the commonly cited problem. When a connection comes in, ALL the threads/procs blocked on the accept wake up but only one is selected to accept the connection. This is a performance problem. 2. lock-ups and seg faults Some systems have some funky timing windows inside the accept() call that will cause threads to hang and or seg fault inside the accept The common solution to fix this problem is to mutex access to the accept() call. The 'problem' with this solution is that it introduces two additional system call per handled connection (lock and unlocl). Some OSes have implemented versions of accept() that do not exhibit the problems above. For these OSes, it is okay to allow multiple threads/procs into the accept call at once, saving the overhead of making an additional lock/unlock call per connection. Apache recognizes these systems by setting the S_L_U_A define in ap_config.h. If S_L_U_A is defined for a particular version of an OS, that tells Apache httpd that it is okay to allow multiple threads/proces into the accept(). So S_L_U_A is defined for those systems that support it, and it is not defined for those systems that do not support it. If httpd is configured with multiple listeners, S_L_U_A is irrelevant because you have to select() before calling accept(). And to the best of my knowledge, it is always bad to have multiple threads/processes block in select(), for all OS'. In the multi listener config, SingleListen will enable the admin to force httpd to make all the threads/processes to block in accept, even if the system cannot reliable support this. Why is this good? The only benefit I see to SingleListen is to enable an admin to turn -off- the S_L_U_A optimization in the single listener case. I have never seen the need to do this. Bill
Re: Comments on accept-mutex/single-listen patch ??
At 10:18 AM -0400 8/28/01, Jeff Trawick wrote: which default stuff is needed in 2.0? Last I looked, APR uses the traditional ordering of which locking method to use. Thus, if SysV, fcntl and flock are available, APR will choose SysV by default, even if it should be fcntl. We know which should be the default from the 1.3 code. why is SingleListen needed? Pretty much to make SINGLE_LISTEN runtime rather than compile time... Again, to give the admins more control over how Apache handles mutexing. So what decides when USE_NONE_SERIALIZED_ACCEPT is a choice? I'd think that if you allow it anywhere you'd allow it everywhere, and that there'd be no need to define anything in ap_config.h. It's on an platform-by-platform basis... Again, what we're doing is telling Apache which mutex methods are *available* on the platform, not neccessaryly what ones to use. Some platforms don't support NONE and they shouldn't be given the option to add it in. We should provide users with as comprehensive a suite of methods as we can, and let them adjust/use/determine which ones at runtime. If they are feeling adventurous (or are in developer-mode) then they can compile in some other suites and see how they work. +/* functions for determination and setting of accept() mutexing */ +char *default_mutex_method(void); +char *init_mutex_method(char *t); +char *init_single_listen(int flag); prefix with ap_... yeah, not everything in 1.3 is namespace-protected, but it is trivial for new functions. +1 + return Request serialized accept method not available; Requested, not Request + return Request serialized accept method not available; same as previous comment, but I'd think one of these should never fail... how about ap_assert() in one of them instead of returning an error that we shouldn't have logic to check for? The 'Request' refers to the actual HTTP request (ie: serialized accept method used in the request) but yeah, I agree that it's confusing. And Requested makes more sense. Recall that these sections deal with runtime checking... If someone adds 'AcceptMethod flark' to httpd.conf, we want Apache to complain and die at config read, which is what happens. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: Comments on accept-mutex/single-listen patch ??
Jim Jagielski [EMAIL PROTECTED] writes: At 10:18 AM -0400 8/28/01, Jeff Trawick wrote: which default stuff is needed in 2.0? Last I looked, APR uses the traditional ordering of which locking method to use. Thus, if SysV, fcntl and flock are available, APR will choose SysV by default, even if it should be fcntl. We know which should be the default from the 1.3 code. The order it checks for (at the moment :) ) is sysvsem, flock, pthread mutex, fcntl. The last match wins (i.e., fcntl is preferred). This can be overridden on a platform basis in apr_hints.m4 by setting the variable apr_lock_method. why is SingleListen needed? Pretty much to make SINGLE_LISTEN runtime rather than compile time... Again, to give the admins more control over how Apache handles mutexing. I'm not totally against it, it just seems that it is for playing around (sort of like USE_NONE_SERIALIZED_ACCEPT) or trying to work around an Apache bug (i.e., maybe there is some platform/version where we're supposed to turn on SINGLE_LISTEN_UNSERIALIZE_ACCEPT but don't). Why can't they compile this in? This would seem to be useful in extremely rare circumstances, and only for somebody who really knows what they are doing. So what decides when USE_NONE_SERIALIZED_ACCEPT is a choice? I'd think that if you allow it anywhere you'd allow it everywhere, and that there'd be no need to define anything in ap_config.h. It's on an platform-by-platform basis... Again, what we're doing is telling Apache which mutex methods are *available* on the platform, not neccessaryly what ones to use. Some platforms don't support NONE and they shouldn't be given the option to add it in. We should provide users with as comprehensive a suite of methods as we can, and let them adjust/use/determine which ones at runtime. If they are feeling adventurous (or are in developer-mode) then they can compile in some other suites and see how they work. Why would a platform not support NONE? I guess I don't understand what you mean by support. Surely you don't mean that it is a wise thing to do on any of the platforms for which you chose to turn on HAVE_NONE_SERIALIZED_ACCEPT??? HAVE_NONE_xxx means that you can turn the accept mutex into a no-op, even in the multiple-listener case. If we can play around with this on one platform (e.g., Darwin), why can't we play around with this everywhere? + return Request serialized accept method not available; Requested, not Request + return Request serialized accept method not available; same as previous comment, but I'd think one of these should never fail... how about ap_assert() in one of them instead of returning an error that we shouldn't have logic to check for? Recall that these sections deal with runtime checking... If someone adds 'AcceptMethod flark' to httpd.conf, we want Apache to complain and die at config read, which is what happens. How can default_mutex_method() ever fail? Doesn't that imply a code bug in the configuration of mutex methods? Isn't it better to ap_assert() right in default_mutex_method() than to ignore the problem and pass init_mutex_method() something bogus (like Request[ed] serialized accept method not available)? Here is the line I'm looking at: + init_mutex_method(default_mutex_method()); Thanks, Jeff -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
At 11:00 AM -0400 8/28/01, Jeff Trawick wrote: The order it checks for (at the moment :) ) is sysvsem, flock, pthread mutex, fcntl. The last match wins (i.e., fcntl is preferred). This can be overridden on a platform basis in apr_hints.m4 by setting the variable apr_lock_method. That's cool. why is SingleListen needed? Pretty much to make SINGLE_LISTEN runtime rather than compile time... Again, to give the admins more control over how Apache handles mutexing. I'm not totally against it, it just seems that it is for playing around (sort of like USE_NONE_SERIALIZED_ACCEPT) or trying to work around an Apache bug (i.e., maybe there is some platform/version where we're supposed to turn on SINGLE_LISTEN_UNSERIALIZE_ACCEPT but don't). Why can't they compile this in? This would seem to be useful in extremely rare circumstances, and only for somebody who really knows what they are doing. Agreed... But there have been times when, as an admin, I wished that I had the capability... this is especially true for those cases where people generate one build that is supposed to be installed and used on a variety of similar-platforms-but-different-specifics (eg: all running Solaris 8, but with different numbers of CPUs, etc). Testing is showing that more runtime control over the whole accept mutex is needed :) HAVE_NONE_xxx means that you can turn the accept mutex into a no-op, even in the multiple-listener case. If we can play around with this on one platform (e.g., Darwin), why can't we play around with this everywhere? Because, at least with the systems I've been testing, it appears to work OK on OS X, and, as such, we should allow others to have the choice. I've no idea if it works under IRIX, and having it as a compiled default implies that we've tested it as such... Basically, I want people to be able to use any of the compiled-in methods and have Apache work (maybe not the fastest, but at least we know it works). If we find out that NONE is supported and viable on other platforms, we'll change things to make it a compiled default, but it's premature to do it *now* without that knowledge. How can default_mutex_method() ever fail? Doesn't that imply a code bug in the configuration of mutex methods? More a compile bug, but yeah, it's designed to handle the traditional should never happen situation. Isn't it better to ap_assert() right in default_mutex_method() than to ignore the problem and pass init_mutex_method() something bogus (like Request[ed] serialized accept method not available)? Here is the line I'm looking at: + init_mutex_method(default_mutex_method()); Yeah... But init_mutex_method needs to handle errors as well... So we're looking at, basically, defensive coding that pumps info into a function which is smart enough to handle bogus info. If default_mutex_method() returned 'unknown' then maybe it wouldn't be so objectionable :) PS: partly, it's my own adversion to asserts :) :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Comments on accept-mutex/single-listen patch ??
Anyone get a chance to look over and try out the latest patch? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: Comments on accept-mutex/single-listen patch ??
Just noticed some typos (ie: SYSVMEM instead of SYSVSEM)... will fix. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: Comments on accept-mutex/single-listen patch ??
On Tue, 28 Aug 2001, Jim Jagielski wrote: Anyone get a chance to look over and try out the latest patch? Looking at it.. (And trying to compare it with what I've got here to make sure I still have all the functionality I needed). Seems all cool sofar. Dw
