The whole point of PRE-forking is that the processes are already forked. Each new connection just waits for an existing process to finish up and move on to handle it. You won't have 70k processes for those 70k users, you'll have up to the number of processes in your dbmail.conf file and the system will have 70k connections on a waiting list for the next available process to handle it.
There is no difference between the SMP support of threads and processes. There might be some interesting performance numbers for various types of tasks, but in terms of actually supporting SMP, there's no difference. A particularly dumb misconception people have about SMP is that it doesn't help unless you have a program specifically designed to handle it. For whatever reason, it never dawns on these people that they might have more than one program open at a time. So what if PhotoPhizzle is single threaded? At least it gets a CPU all to itself while your instant messenger, mp3 player and web browser run on the other CPU. One does not "just test some pthreads patches." Threading is a lot of work. Aaron Dan Weber <[EMAIL PROTECTED]> said: > The libtool gave some memory benefits which were quite nice. I > personally don't think preforking will be very good in the end due to > certain situations. If you have 70k users, they all ping up the > imap/pop at the same time, its going to be eating a ridiculously large > amount of resources and time with preforking. Especcially since its > spawning a new process for each client, and it is also cloning the > resources. This essentially will eat the living daylights out of > memory. Pthreads seem to inherit resources and won't allocate new ones > each time. They also seem to spawn faster and can get some nice > benefits on SMP machines. Maybe I can find some time to submit some > pthread patches to show. > > Dan Weber > > Dan Weber wrote: > > > Aaron Stone wrote: > > > >> Your goals sound really good. But as for the plan... Are you forking > >> because > >> you want a different code structure or because you want a completely > >> independent project that is not going to be compatible with mainline > >> DBMail? > >> > >> > >> > > Actually I was really only going to fork if things didn't go my way. > > The mail management system idea I thought was pretty good, then you > > can molt it to your needs. I never thought upstream would like the > > idea. I could probably finish the code for dlopen later so you could > > easily swap modules in and out without issues. I have been working on > > an ODBC driver for this for a little while, I think I am actually > > getting somewhere on it atm. > > > >> After 2.0, we're planning on changing the database structure to > >> better handle > >> header and mime caching, as well as a few other refinements. > >> > >> I'm more than sure that people here would like to see a > >> "libdbmail.so" that > >> exposed the message delivery and retrieval functions, and still have > >> those > >> functions be shared with the real DBMail to maintain compatibility. > >> > >> Don't fork to add features that people in the mainline want, too. > >> > >> > >> > > I need to remind myself to cleanup the headers so you can setup an > > include distribution for writing extensions to dbmail. Essentially > > any person could write their own filtering system as a module to > > dbmail. This will finally allow for a dbmail-common package in debian > > which is heavily needed. I think its getting pretty ugly and so is > > the rules file ;) > > > > The sbin patch was necessary. When was the last time you saw a daemon > > that had to bind < 1024 in /usr/bin? > > > >> Aaron > >> > >> > >> Dan Weber <[EMAIL PROTECTED]> said: > >> [snip] > >> > >> > >>> ... I started working at this because I plan to fork dbmail as > >>> soon as it hits a solid 2.0 release. I was going to split it more > >>> into a mail management system and take away the pop and imap. Then > >>> I would provide libraries and headers to write frontends to it. > >> > >> > >> > >> > > Online management of the databases directly through libdbmail.so and a > > GUI api interface would probably be popular. > > > > Dan Weber > > > >> -- > >> _______________________________________________ > >> Dbmail-dev mailing list > >> [email protected] > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > >> > >> > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Dbmail-dev mailing list > >[email protected] > >http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > > --------------enig084699073393F76AB1E824E8 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFAssipF6i3K/AxoQERAm6SAJsHqWRYFDjvxtZxXdYRrl4rlbodiQCcD4OG > zxXEVlEsD1eCgcsrU2Jt594= > =yldf > -----END PGP SIGNATURE----- > > --------------enig084699073393F76AB1E824E8-- > > --===============0299285599== --
