ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 ?
Originally posted by AbEnd Ever heard of multiplexed (man 2 select poll kqueue) or signal driven (man 2 fcntl) IO? AFAIK multiplexed might be generally faster than threaded.
You're wrong to categorize some of those daemons as "uses fork for parallel stuff", some uses fork for other things (not based on the connections).
What you should use really depends on how you want it to work, not just performance... I think inetd is good for telnet because it isolates the different sessions (since telnet is important) and FTP cause you can change the creds of the processes.
But HTTP always get alot of [new] connections, that's why thttpd uses multiplexed IO, Apache 1 uses preforking, Apache 2 can use threading, etc.
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.
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).
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 ??
What is the max number of threads/fork that can be created a process/parent process..?
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.