Daniel Feiglin wrote:
Is this some kind of thread per client application?
If it is, you might like to take a look at the good old C library select(2) api which has been somehow implemented in Java 1.4.x (see for example, API doc java.nio.channels.SelectableChannel). I haven't used this Java API myself, but if it's anything like the C select(), you can handle many channels in a single thread or process, so cutting down the total number of threads/processes. You'll need to check out the maximun
I'm not sure it will give him better performance than thread-per-client.
You see - a single thread looping through all the descriptors means that
each descriptor waits for all the rest for its turn to be handled. If (or actually
"when") the handling of any of the descriptors blocks it means that everything else
halts.
In addition, you have to keep state for each descriptor - what was the last thing
heard from it? when was it? (should you decide on time out?) what is expected next?
You have to be careful not to block anywere because then you screw everybody.
Not to mention that you loose the advantage of multi-CPU.
When using threads, on the other hand, you can program each thread to handle
its own connection, block whenever is necessary, the state is kept for you
automatically on (or throught) the stack, and the system will switch to another
thread automatically whne your thread blocks (be it on a disk wait, SQL query,
whatever).
I'm talking from experience - I've programmed multi-connection servers for many
years (C/UNIX) before startting using threads (C++/Windows, C++/Unix and now
Java), all the problems involved around using select/state/blocking are gone when
programming with threads.
I wonder how Apache (which I assume everyone would agree is a respectable server)
does things - as far as I can tell it uses the "multi-thread" method (be it "thread-per-process"
or threads in one process, but the point is that it allocates a thread of execution for each
connection).
Now you say that the benefit of using select is to cut-down the number of threads/processes -
what do you expect to gain from this? Reduce memory use? If you accept my view that "a thread is
defined basically by its stack" then all you gain is the thread's stack, which is usually not more
than a few KB, i.e. not more than a few MB when multiplied by "a thouand threads", it's
negligible amount of memory and you'll need it for state "book-keeping" anyway if you
go down the "select" path.
nunber of open filehandles allowed per process. You might need to do a kernel compile to bring it upto something reasonable.
I think that limit would be an obstacle whether he uses multiple threads or select.
Anyway, that's my penny's worth for the day.
What do you say?
Cheers,
--Amos
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
