http://blog.lighttpd.net en-us 40 @Ted Moving to NGINX wouldn't be a bad idea. Tue, 01 Apr 2008 00:02:52 +0000 urn:uuid:8dd98300-dc53-4fc8-8c11-c1bac8d76236 http://blog.lighttpd.net/articles/2008/03/05/pre-release-lighttpd-1-4-19-r2118#comment-5425 That is true, but only if your one malloc() was for an insane amount of pages. Of course one can turn of the overcommit quite easily, but I think that you would be caught by bugs in quite a few applications then. I think that the reason behind glib2's use of abort() is that if you receive NULL from malloc() you have a 99% chance that the heap is corrupted and you better abort your process. The situation that Tom described where lighty would be terminated when handling to many simultaneous connections is one situation where NULL would practically never ever be returned by malloc() due to the overcommit in linux. Thu, 13 Mar 2008 16:51:36 +0000 urn:uuid:2de099ab-d0d8-4b24-9878-c27f3daada0f http://blog.lighttpd.net/articles/2008/02/19/project-glib-it-compiles-mostly#comment-5384 Henrik: Actually memory allocation on Linux can fail if you try to allocate too much over the top (see linux/Documentation/vm/overcommit-accounting). Thu, 13 Mar 2008 15:37:59 +0000 urn:uuid:9bc7a6a7-f675-48b7-88ab-13499c57e7e0 http://blog.lighttpd.net/articles/2008/02/19/project-glib-it-compiles-mostly#comment-5383 Tom: Memory allocation in Linux does not return NULL on out-of-memory, libc will only return NULL if it detected a corrupted heap. Linux will only perform the allocation itself when you actually use the memory so there is no way to tell you on malloc() time that you are out of memory, so calling abort() on failed allocation is the only sane way to do it so glib2 performs correct. Thu, 13 Mar 2008 09:52:58 +0000 urn:uuid:840ca716-4009-47b2-a66f-a704320f07aa http://blog.lighttpd.net/articles/2008/02/19/project-glib-it-compiles-mostly#comment-5381 jan, Can you provide some insight on why the move the glib?v Thanks. Wed, 12 Mar 2008 15:49:05 +0000 urn:uuid:60c2b262-8c03-46d1-a1ef-e440065bab9f http://blog.lighttpd.net/articles/2008/02/19/project-glib-it-compiles-mostly#comment-5376 Yeah, that's great work. Keep on. Never had any problems with lightty and it's serving plenty of gigabytes a day for months. Tue, 11 Mar 2008 23:49:15 +0000 urn:uuid:1b888024-5239-4dcf-8b23-fbd9bb60fb18 http://blog.lighttpd.net/articles/2008/02/19/project-glib-it-compiles-mostly#comment-5372 Good work! I'm waiting for 1.5.x :) Mon, 10 Mar 2008 20:19:07 +0000 urn:uuid:2ad9465c-69b3-46d0-956e-a79beb8330db http://blog.lighttpd.net/articles/2008/03/05/pre-release-lighttpd-1-4-19-r2118#comment-5358 I have taken the risk of putting this into a production environment and have had it running for a few hours now. We've been monitoring the traffic and it all seems to be working well. Great job Jan, lets hope to have a .19 release sometime soon. Fri, 07 Mar 2008 23:38:37 +0000 urn:uuid:50a7f3c7-08b4-4d6f-8a87-87e76e77ee0a http://blog.lighttpd.net/articles/2008/03/05/pre-release-lighttpd-1-4-19-r2118#comment-5319 Should I be using NGINX? Thu, 06 Mar 2008 21:23:46 +0000 urn:uuid:152a1d83-b841-4946-af64-900a7e43b4c5 http://blog.lighttpd.net/articles/2008/03/05/pre-release-lighttpd-1-4-19-r2118#comment-5304 Good news! Awaiting for release. I've turned to lighty while being searching for a solution to my problem with Apache. With lighty I was able to solve it in a few minutes. And it's fast. And has a very small footprint. And..... Thu, 06 Mar 2008 15:32:35 +0000 urn:uuid:56861b95-d187-4015-983a-4ada91d7a08f http://blog.lighttpd.net/articles/2008/03/05/pre-release-lighttpd-1-4-19-r2118#comment-5302