Re: Approaches to serve multiple clients
Re: Approaches to serve multiple clients
- Subject: Re: Approaches to serve multiple clients
- From: Quinn <email@hidden>
- Date: Tue, 1 Feb 2005 06:54:07 +0000
At 0:02 +0300 19/12/04, Igor Garnov wrote:
1) I can fork with each connecting client [...]
2) I can use 'select' [...]
3) You can use threads to handle each client.
Your first choice is between the two fundamentally different
programming models.
o fork and threads allow you to have a thread of execution per
client, which makes for a simple blocking model for networking. This
is nice for some things, but it's a pain if the clients share data
because you have to coordinate access to that data (mutexes when
using threads, shared memory when using fork).
o select does everything with a single thread of execution. This
means you have to use a state machine programming model (some folks
love state machines, some hate 'em, it's really a question of how
your brain works). OTOH, it makes it much easier to coordinate
access to shared data because no locking is required.
This is the first choice you should make. After that, if you choose
a blocking model, you then get to choose between fork and threads.
o fork requires you to use a process per client. This has two disadvantages:
- Processes are more heavyweight vis-a-vis threads. Mac OS X's
implementation of fork is more heavyweight that you might find
on other platforms.
- Communicating between processes is harder, because you not only
have to deal with the mutexes but you also have to coordinate
to share the data via shared memory [1].
[1] This assumes you want a memory-based communications model. You
could use some other model (message passing, sockets), but I'm not
sure that's going to make things easier.
o threads are more lightweight, but they are also more vulnerable.
All of the threads share the same address space, so if a single
thread loses the plot it crashes your process, which takes down all
of your clients.
You can also combine models. For example, if you need to handle lots
of clients concurrently, you might choose to use the state machine
model, but then start multiple threads (or processes) to run one
state machine per CPU on the computer. Or, you could do the work in
threads but distribute the clients amongst N processes, which would
limit the damage a single rogue thread could cause.
Moreover, this frightens me a little, because if there are, say,
1000 clients, there also are 1000 processes.
Running 1000 process concurrently is a bad idea on Mac OS X.
Starting 1000 threads within a single process is not such a great
idea either, but it's certainly better.
This is no problem for Apache, because the lifetime of each its
process is very short [...]
Actually, that's not true. Starting up and shutting down a process
represents a significant cost. It's not something that you should do
lightly.
Is it OK to have 1000 processes at the same time? What if there are
2000? 3000?
No, no, and, no.
Mac OS X probably will handle you launching 1000 processes
concurrently, but it's definitely not the best use of resources.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden