Re: [Libevent-users] thread-safety bug report with patch
On Tue, Feb 26, 2008 at 10:12:08AM -0800, Tani Hosokawa wrote: These are four broken functions that didn't make it into the latest release -- I noticed that one of them is even marked as not being thread-safe. Thanks! I've checked your patch into trunk and into the 1.4 branch. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] performance patch
On Wed, Feb 27, 2008 at 02:54:41AM +0300, Vsevolod Stakhov wrote: Tani Hosokawa ?: snip significant amount of processing to do per request. The reason I put 1024 in there is all implementations that I know of silently truncate the backlog parameter to the system's maximum. The reason I don't use SOMAXCONN is some OS (older Solaris for sure) are incorrect for backward compatibility reasons, and other OS are incorrect because the actual setting is dynamically tunable via sysctl. snip As POSIX requires SOMAXCONN to be defined in sys/socket.h it is safe to use this value or define some constant in configure script, that detects SOMAXCONN definition. Also in old Solaris systems backlog was limited to 5. The problem with SOMAXCONN is the same as FOPEN_MAX (ISO C). The runtime limit is not the same as the compile-time constant. In fact, usually the runtime limit is much higher. On all of my boxes FOPEN_MAX is defined to be 16 or 20. Yet that is definitely not the runtime limit. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] performance patch
On Tue, Feb 26, 2008 at 12:41 PM, Tani Hosokawa [EMAIL PROTECTED] wrote: Under high load, unless you build a dedicated acceptor thread you will find that only allowing a listen backlog of 10 connections will cause lots of attempted connections to simply be dropped if you have any significant amount of processing to do per request. The reason I put 1024 in there is all implementations that I know of silently truncate I just submitted a change to trunk yesterday that raiseed the limit to 128. I also added a new API, evhttp_accept_socket(), to which you can provide an already created fd for which you could set the listen queue to whatever you like. Niels. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] dns server availability check / google.com
Hi, while looking into an async dns solution i found the code to recheck dns servers in libevent. I dont think checking for google.com is a very good choice. In the past even ccTLDs have disappeared or start to disappear (.su, .dd, .yu) despite companys renaming, disappearing or having hicups. Hopefully libevent will last much longer than google and suddenly applications start to fail in mysterious ways because people did not upgrade in the last 5 years. So the only real static solution i would see is a NS query for . e.g. Root Nameserver NS addresses. Although all of these choices would not really help in case of a nameserver responding with cache content but not beeing able to resolve (forwarders down or unreachable). A much better option would be to once every now and then requeue a real query for the nameserver beeing down probably a dupe of a real query and check with that. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
