On Wed, Jan 31, 2007 at 05:08:18PM -0500, Matthew T. O'Connor wrote: > Marc Dirix wrote: > >threading is better suited for memory management and limitation. > > How's that exactly? Using unix fork() which is copy on write, forking > many processes tends to be very memory efficient.
Processes tend to do lot's of memory writes, certainly in an use environment. I meant here that a seperate thread can be instituted to do garbage collection of used memory. > > >threading is more controllable during a DoS attack. > > I've never heard this before, please expound. When using a monolithic threading model, the socket is only opened to the main thread. This main thread will create handler threads if someone sends data to the socket. In this model all new connection are handled sequentially, however the return values can be asynchron from each thread. The main thread can easily manage both traffic shaping/limiting and drop multiple connects from the same client. This agains a multi-process model where there are x default handlers trying to beat eachother to the socket when a client connects. There is no control whatsoever about the socket. There are thread library's specially designed for being used in a service environment. > > >threading if done right, will provide better scaling abilities (see > >roxen versus apache). > > I don't know much about roxen, but I think lots of things will scale > better than Apache since Apache by design is a kitchen sink type program. > That is actually the other way around. Apache is a webserver. If scripting or whatever is needed one has to look for external compilers like php or perl. However Roxen is a webapplication server, it has a internal (RXML) parser which can do just about everything you need for dynamic pages. (And also if needed interface to php/perl). The problem with apache is in the fact that to be able to handle N connects it has to create N childs which eventually will limit to a maximum. This doesn't scale well. A model where only one socket exists and connections are handled sequential will scale very well until system limits that is. > >threading will provide us eventually with a more sleak and clean design, > >because it does not allow for the apache programming model in the sense of: > >"We have this child, it leaks memory so lets kill it after x connects en > >start a new one." > > This sounds like a threads are better because they are argument. The > benifit of being able to kill off a process with memory leaks is that > the server still runs, if you have the same memory leak in a treaded > app, you have to restart the whole server. > That's the sloppy programmers kind of view. "We know we leak, but instead of fixing it we will kill our children". > I'm not against threading, I'm just concerned that we are going to add a > ton of complexity for very little gain. That is true, it will take a steep programming curve to do right. And sure it will take a long time before dbmail is back to the current level, however now is the time to make such a decission not after putting another year of effort into 2.3. The next chance would only be after 2.4 release. Marc _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
