Hello Matthew, Am Montag, 4. Oktober 2004 um 22:58 schriebst du:
> Gerrit P. Haase wrote: >>Ok, I'm running this on Windows using Cygwin postgres / dbmail, >>everything is usually 10 to 100 times slower, but I know that database >>applications can run fast on Windows too. Sure, Cygwin slows down >>things. I installed it on the Windows box for testing, at least it >>builds ok and it runs. But often dbmail seems to hang. It finally >>finishes the work but I suspect htere to be some serious problems. > At this point I would recomend installing the PostgreSQL 8.0 beta that > has native support for Windows. Even though it's still a beta I think > it performs better and is probably more reliable than the cygwin port. > Please give it a try and let me know if you are still having problems. Nah, the installer uses W2K unique features to install it as a service anfd this fails on my NT4 box. Maybe I can run it without setting up the services. > BTW is there any reason we cant' have a native windows port of DBMail? Since it seems to be all plain C it should not be too hard, see here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_port_from_unix_to_win32.asp >>Thats the reason why I started the thread about 'Threads support', on >>Windows using threads is very fast and speeds things up about 10 to >>100 times and then it would be as fast as it is now on Linux. > Care to substantiate that comment? Please provide a concrete example of > where threads are that much faster and under what situation. Threads > are not a magic solution, they have some upsides but they also have some > very serious downsides, and they are a major change to the dbmail code. It deoends on the application you want to implement whether threads or other models are better. I believe that in the same moment as serving clients over a network is involved it is always better to use some kind of threading. General: Threads are faster because they share the code and data segments, only the stack is unique in opposite to separate tasks where every task has its own data segment and its own stack, tasks only share the code. Therefore is the creation of a thread faster than creation of a task. You have another great advantage, that is interprocess communication which is much easier among threads (through variables). Disadvantages: - If an error occurs in one thread it can kill the whole process with all other threads. - Interprocesscommunication needs to be synchronized. Another problem: Linuxthreads are lightweight threads and they are in fact not much faster than separated tasks. That is because they are not kernel threads. Maybe it works better with the NPTL and newer kernels? I suggest to use multithreading for the native Windows port you're aiming at, and for Linux make it optional like in Apache2, use preforking, threaded, hybrid multi-process or multi-threaded, but fast for Windows is only the option multithreaded mode. Interesting notes about threads on *nix systems: http://www.kegel.com/c10k.html Gerrit -- =^..^=
