Archived

This topic is now archived and is closed to further replies.

Threaded server

This topic is 5270 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In setting up a server on Unix, would threads be the way to go or would forking a new process? I think I''ll know ahead of time exactly how many threads (or processes) I''ll need. For instance, I would want one thread that simply does nothing but listen (or recvfrom) on a socket. This would block so I am planning to put this in it''s own thread. I also want a thread that executes processing a received packet once the other thread has actually received it. In addition that that would be threads for other cut and dry processes. I''m thinking of having multiple threads calling recvfrom if that''s possible to handle the times when network trafic gets heavy. Likewise multiple threads to actually service the packets once they arrive. Would making multiple threads like this be faster that a single thread that processes each packet in the order they are received? I''m assuming on a multi processor system that it would be and this would definitely run on a nice machine if it ever gets anywhere. I''m thinking of an adaptive thread number. Something where only a single thread is woken if I have fewer than 10 clients. Wake a second thread if I have 10 to 20 clients (or some other arbitrary number). This way the initial work of creating the threads (or processes) is done at startup and then they would be there when necessary. Your thoughts? Threads or forking? Sleeping thread pool or create and destroy threads as necessary? Single thread for a function? Or a thread pool to use when more clients are available? Also, any good tutorials with threads and forking as applied to servers of this type? I have some good reference material here in books but as always I could use more. Have another question but it''s not really related to this so it''ll be on another thread. Thanks for any input, Webby

Share this post


Link to post
Share on other sites
> Threads or forking?

Anything that would require heavy modifications to the heap data without necessarily having shared data amongst connected clients could be fork()''d. If data absolutely needs to be shared amongst clients, then you''d have no choice but to use threads and insert thread-locking mechanisms to protect the common data. There is a grey area in between where the decision is not that obvious to make. Here are some more info about threads vs fork():

fork() involves partial process duplication. Although the process PID is cloned (as well as the file IDs and other process-dependent stuff), heap memory is shared (code is always shared by memory mapping unless you are debugging). From the scheduler''s perspective, there are only minor differences between threads and single-threaded processes. But here''s the kicker: once a process commits a ''write'' change to the heap memory, then that process''s 4K page block where that change is made is duplicated. If your application changes a few of byte here and there in few of these blocks, then most of the heap will be shared. On the opposite, if all the heap memory blocks are write-touched (i.e. by sorting a huge array), then the processes are fully duplicated, almost to the last byte; then you get a nice pair of memory hogs. They are two complete applications in memory even though they are of the same executable. An executable that manages the heap data very well by coalescing read-only blocks (i.e. like a BSP map or texture images) or by providing fixed-block size allocation will obviously minimize the impact of the 4K blocks duplication (hint: always build your own memory manager instead of relying on malloc/free).

A good discussion of threads/fork discussion in the case of web servers can be found at JAWS under ''Concurrency Strategies'': http://www.cs.wustl.edu/~jxh/research/research.html.

Hope this helps.

-cb

Share this post


Link to post
Share on other sites
WebsiteWill: Info on coding threaded workcrew applications under POSIX (unix, linux, *nix). Go to IBMS developerworks (excellent website) and find Daniel Robbins articles about posix threads :-). For a game engine forking would perhaps not be a good idea because it''s much harder to share data between the processes. And yeah I know that posix threads are implemented as processes, but you don''t have to set up the shared memory space yourself and your server is portable to every posix platform.. at least the threaded part of it :-)

Share this post


Link to post
Share on other sites