Re: squid-smp: synchronization issue & solutions
On 11/15/2009 11:59 AM, Sachin Malave wrote: > Since last few days i am analyzing squid code for smp support, I found > one big issue regarding debugs() function, It is very hard get rid of > this issue as it is appearing at almost everywhere in the code. So for > testing purpose i have disable the debug option in squid.conf as > follows > > --- > debug_options 0,0 > --- > > Well this was only way, as did not want to spend time on this issue. You can certainly disable any feature as an intermediate step as long as the overall approach allows for the later efficient support of the temporary disabled feature. Debugging is probably the worst feature to disable though because without it we do not know much about Squid operation. > Now concentrating on locking mechanism... I would not recommend starting with such low-level decisions as locking mechanisms. We need to decide what needs to be locked first. AFAIK, there is currently no consensus whether we start with processes or threads, for example. The locking mechanism would depend on that. > As OpenMP library is widely supported by almost all platforms and > compilers, I am inheriting locking mechanism from the same > Just include omp.h & compile code with -fopenmp option if using gcc, > Other may use similar thing on their platform, Well that is not a big > issue.. After spending 2 minutes on openmp.org, I am not very excited about using OpenMP. Please correct me if I am wrong, but OpenMP seems to be: - An "approach" or "model" requiring compiler support and language extensions. It is _not_ a library. You examples with #pragmas is a good illustration. - Designed for parallelizing computation-intensive programs such as various math models running on massively parallel computers. AFAICT, the OpenMP steering group is comprised of folks that deal with such models in such environments. Our environment and performance goals are rather different. > 1. hash_link LOCKED > > 2. dlink_list LOCKED > > 3. ipcache, fqdncache LOCKED, > > 4. FD / fde handling ---WELL, SEEMS NOT CREATING PROBLEM, If any then > please discuss. > > 5. statistic counters --- NOT LOCKED ( I know this is very important, > But these are scattered all around squid code, Write now they may be > holding wrong values) > > 6. memory manager --- DID NOT FOLLOW > > 7. configuration objects --- DID NOT FOLLOW I worry that the end result of this exercise would produce a slow and buggy Squid for several reasons: - Globally locking low-level but interdependent objects is likely to create deadlocks when two or more locked objects need to lock other locked objects in a circular fashion. - Locking low-level objects without an overall performance-aware plan is likely to result in performance-killing competition for critical locks. I believe that with the right design, many locks can be avoided. I think our first questions should instead include: Q1. What are the major areas or units of asynchronous code execution? Some of us may prefer large areas such as "http_port acceptor" or "cache" or "server side". Others may root for AsyncJob as the largest asynchronous unit of execution. These two approaches and their implications differ a lot. There may be other designs worth considering. Q2. Threads versus processes. Depending on Q1, we may have a choice. The choice will affect the required locking mechanism and other key decisions. Thank you, Alex.
Re: libresolv and freebsd
Yes. I'd also like to give a nice reworking to the pthread-detection logic which seems a bit overcomplicated (also, on Opensolaris pthread_* are now libc, with stubs in libpthread and libthread). K. On Mon, Nov 16, 2009 at 3:50 PM, Henrik Nordstrom wrote: > Quite likely we don't even need libresolv in the majority of cases, on > pretty much all platforms. > > mån 2009-11-16 klockan 12:07 +0100 skrev Kinkie: >> In configure.in there is something like this: >> >> if test $ac_cv_lib_bind_gethostbyname = "no" ; then >> case "$host" in >> i386-*-freebsd*) >> AC_MSG_NOTICE([skipping libresolv checks for $host]) >> ;; >> *) >> AC_CHECK_LIB(resolv, main) >> ;; >> esac >> fi >> >> I fail to see what's the point in skipping this test. >> I'd expect to get the same result with a simple(r) >> >> AC_SEARCH_LIBS([gethostbyname],[bind resolv]) >> >> See my other request on moving form AC_CHECK_LIB to AC_SEARCH_LIBS. >> >> Thanks for any input. >> > > -- /kinkie
Re: libresolv and freebsd
Quite likely we don't even need libresolv in the majority of cases, on pretty much all platforms. mån 2009-11-16 klockan 12:07 +0100 skrev Kinkie: > In configure.in there is something like this: > > if test $ac_cv_lib_bind_gethostbyname = "no" ; then > case "$host" in > i386-*-freebsd*) > AC_MSG_NOTICE([skipping libresolv checks for $host]) > ;; > *) >AC_CHECK_LIB(resolv, main) > ;; > esac > fi > > I fail to see what's the point in skipping this test. > I'd expect to get the same result with a simple(r) > > AC_SEARCH_LIBS([gethostbyname],[bind resolv]) > > See my other request on moving form AC_CHECK_LIB to AC_SEARCH_LIBS. > > Thanks for any input. >
Re: libresolv and freebsd
Kinkie wrote: In configure.in there is something like this: if test $ac_cv_lib_bind_gethostbyname = "no" ; then case "$host" in i386-*-freebsd*) AC_MSG_NOTICE([skipping libresolv checks for $host]) ;; *) AC_CHECK_LIB(resolv, main) ;; esac fi I fail to see what's the point in skipping this test. I'd expect to get the same result with a simple(r) AC_SEARCH_LIBS([gethostbyname],[bind resolv]) See my other request on moving form AC_CHECK_LIB to AC_SEARCH_LIBS. Thanks for any input. Agreed. It's probably worth melding into the test patch for AC_SEARCH Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14
libresolv and freebsd
In configure.in there is something like this: if test $ac_cv_lib_bind_gethostbyname = "no" ; then case "$host" in i386-*-freebsd*) AC_MSG_NOTICE([skipping libresolv checks for $host]) ;; *) AC_CHECK_LIB(resolv, main) ;; esac fi I fail to see what's the point in skipping this test. I'd expect to get the same result with a simple(r) AC_SEARCH_LIBS([gethostbyname],[bind resolv]) See my other request on moving form AC_CHECK_LIB to AC_SEARCH_LIBS. Thanks for any input. -- /kinkie
[MERGE] Improve some libraries detection logic.
Attached is a patch which changes some AC_CHECK_LIBS to AC_SEARCH_LIBS . Autoconf documentation implies that it's somewhat safer, and should be a superset of the former anyways. It's probably sane to convert more calls to this function, but before committing to it I'd like more input. Kinkie # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: kin...@squid-cache.org-20091116105236-g580dhhu2tllxn4w # target_branch: http://www.squid-cache.org/bzr/squid3/trunk/ # testament_sha1: ab4eeecbf4b26b7fffb41310c59c096994876f03 # timestamp: 2009-11-16 11:55:46 +0100 # base_revision_id: squ...@treenet.co.nz-20091114104839-\ # 8nmf5pae5fq3mxsv # # Begin patch === modified file 'configure.in' --- configure.in 2009-11-13 10:28:30 + +++ configure.in 2009-11-16 10:52:36 + @@ -2885,8 +2885,8 @@ #include ]) dnl Check for needed libraries -AC_CHECK_LIB(nsl, main) -AC_CHECK_LIB(socket, main) +AC_SEARCH_LIBS([gethostbyname],[nsl bind]) +AC_SEARCH_LIBS([bind],[socket]) AC_CHECK_LIB(opcom_stack,main) dnl Check for Winsock only on MinGW, on Cygwin we must use emulated BSD socket API case "$host_os" in @@ -2957,16 +2957,15 @@ esac fi -AC_CHECK_LIB(bsd, main) +AC_SEARCH_LIBS([strlcpy], [bsd]) AC_CHECK_LIB(regex, main, [REGEXLIB="-lregex"]) -AC_CHECK_LIB(bind, gethostbyname) if test $ac_cv_lib_bind_gethostbyname = "no" ; then case "$host" in i386-*-freebsd*) AC_MSG_NOTICE([skipping libresolv checks for $host]) ;; *) - AC_CHECK_LIB(resolv, main) + AC_SEARCH_LIBS([res_init],[resolv]) ;; esac fi # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWWcKNJsAAZNfgAAwUef//3tk GAq/7//wUAO5edLtc1cm2pYShIU/U1PTRqbU81I9TT0Q0MjTQBk9BAkopPGgTMVP1EwTRoaAA0aA DQaammim0pmU9NTeqeiaAADEaaeoNDQc0xMACYAJgABMAATBJIIBpNNNUz0GqPU9pIzUPUekNA0e oE4a6stKH2/A03pEFKDHA+axaADEJCc1yUK6evBvjQxJQXsAu0wrkzxxEYi4wZzlx3X03a7692xz 4PXaUvjYObhnhZLS7JjWrwRGahwGzNv+Qb7DCoXyT+RRLCtliBmLgeb4w05rWt6YDQYW5Q5ox1zl bJmDXK58MxGXN5xvMhyDA2FYiRB4HdYBTKZOFRiIcIrLbm3wcT1vHXFPj8lCbWOsHzCvdad/N3jL CBQdaqcJNqqEagvNBOK+uFKqGFEgKwgf0V8R8QoaoDCE7KBQqjQnyizhUNYmJiTJ1i1Dig6mcUIX kMsbYYRdZgMI3JS7CahRpH0o6lpJWik8axIhLg6wvNiSEMVqSLlRkkIBktxwYOBCSn3igWNSEjqS smTjUUSrUJmmLFOIoLsolYwTlRYUlKl8mIqR6iIRukS0CohNJFO60RC8yiPGUz7Bm8lg4kVnKBSk x7rsBYgUuB28NoW+wSS/obwq4g8LQYLpV2qouOvOteKJ3AJwigkGBm+nvGDKdp9s+Q1R4gZuZVnA PnapPKZkO6Lpr8C4sCRae82cbaGw5USiJTWLoPQCU+KoxeRkBfyGpMGDUtdI9AnLvE4EFG1RVw4g EnExeRLrcRbi/RtzyW8CD/iMjhPItWgaccLDYSAxyOGa6cMQ+42FHHm4MQUWqSwIlCnLkCKnsZBb 621RmAqU9rE4kKogVr10aMDFiXlIDMWQuO/v/lquMQYCrl2i7Nwm36kOufrdh7QXMNwEJyo2CcY9 6mDMlS8D4boT4UslxzAu3w1VmgWMCcLsek0ot4M8OpJqM2WykSK2SNROwvI56TQrIKU+uiBt7E6c YmbhMFea3EwRYTVJibexB7roinshlmuOQbOztweQnQe5ymRsCkClbXrvumK8OSz58ymKAlXiooGT 3PuUAWOSsDd0Fi31qoRkLtcnsT6wLKKKYJn3hyaYiwyYiMNoHW+hUF4DeudXT2/4Dy7qiKk4J24L TFad7x+iJpGfbaTv8LPSRNvQVQRUU1qnYrWnEl2/QLTY6KZqH72ArTwOsUwtScl+ldY2R0MkqNiH /4u5IpwoSDOFGk2A
[RFC] AC_CHECK_LIB or AC_SEARCH_LIBS?
Hi all, I stumbled on some autoconf documentation (http://www.gnu.org/software/hello/manual/autoconf/Libraries.html) which kind of implies that AC_CHECK_LIB - which we generously use in our check scripts - may have an improved replacement in AC_SEARCH_LIBS. So what should we do? Should we not touch what is working? Generally try and replace with the suggested function? None of the above? Cheers, -- /kinkie
