fork vs thread/pthread
 

To built a TCP server(the most simplest is a tcp echo server), there two ways to support multi-client connections in general: fork and pthread/thread.

fork is more expansive than thread, I think fork is the old fashion things, and thread should be pop in some new softwares. But when I take quick look("grep -r") on some very pop server's src, I surprisingly found that most of them use fork and only very few of them use thread/pthread.

Fork:
telnetd(freebsd), vsftpd, proftpd, Apache13, Apache2, thttpd, firebird(a bbsd, not the database), PostgreSQL, MySQL-323

pthread:
Apache13, Apache2, MySQL 323

If I want to built a new server, which should I use? fork or thread?
Any suggestions? Or other alternatives ?

Well fork is pretty universal; it'll work on any UNIX system. Most UNIXs support POSIX threads by now, but the quality of the implementation varies.

I'd use pthreads, because they're much easier to work with (since you can easily have access to data structures shared between threads, etc.)

Alex

I use pthreads, too. They're 'lighter' and it's easier to share data.
You can also use 'select' (use 'man 2 select' for more info).

I also post a thread on bsdforums.org, I get some other opinons, I think you may be interested.
http://www.bsdforum.org/forums/showt...threadid=10384

Which is best for implementing SMTP servers in unix.. fork or pthread ?

On Linux it is said that "processes are threads", so there's not much of a difference if these new processes do some precise jobs without tinkering with global data that triggers the Copy-On-Write scheme so they work on their own environment. There is an entire chapter in Stevens' book on many of the approaches that you may use on servers: preemptive forks, threads and so on. With threads, be prepared to use locking around global data. It would be better to start the core of the server itself and networking/protocol stuff and later try the threads stuff.

Personally i would use fork, because of the following reasons:

1) Fork is more universally accepted than threads.

2) Considering the type of application which you are working on, there wont be much of Interprocess communication (ipc) required. Actually threads
really win the race when it comes to inter communication. Since threads share the same memory space hence sharing data between them is really faster as
compared to seperate processes. Where you have to either employ costly approaches like pipes, fifos, shared memory etc.

3) Developement is much easier on a fork based implementation.

4) Fork based implementations are far more maintainable.

5) If the application is in C, then it must be having some global data. In a multi threaded application, all that global data *must* be protected with locks,
since it will be shared by all the threads. And locks can prove very costly (refer to the laws of mutual exclusion and critical sections). In contrast in
a multi process implementation each process has its own copy of global data.

Regards,
Sibtay

(sorry, i forgot to add in my previous post)

I have'nt discussed the advantages of threads. However it should be considered that if properly designed and implemented threads give you
more speed (because there aint any process level context switching in a multi threaded application).

Thanks friend

the stevens' book says don't use threads.
that's good enough for me.

http://www.radwin.org/michael/blog/2...d_harmful.html

Beware the "XYZ sucks" stance and carefully weigh the alternatives. Please tell me where does Stevens say "don't use threads".

I got confused now....shall i use thread to implement a SMTP relay server...?
What is the max number of threads/fork that can be created a process/parent process..?
My friend is using fork to implement the SMTP relay server....I thought of using thread..
What shall i do now ??

Run "getconf CHILD_MAX" in the shell. It prints the value of the sysconf(_SC_CHILD_MAX) call. It's related to process limits (run "ulimit -Ha" and "ulimit -Sa") that may be increased and/or decreased by normal users with some limitations (see "man getrlimit"). Also, in some Unix systems, the hard limits may be increased by means of a sysctl() call.

It's easier to share global values in threads, but be aware that in 2.6 kernel they are created as lightweight processes within the main thread/process, so you only get 1 pid.
If you don't need to share data, then fork is an option and each process will have it's own pid.
I've written a threaded Perl prog that works fine on 2.4 & 2.6 kernel, but I need some global shared data. Note that in Perl, NO vars are shared by default, so it's easy to avoid cross-thread variable update issues.

I find this link which could be helpful in clearing few facts about forking and threading.

http://www.geekride.com/index.php/20...-linux-kernel/