Daniel Malmkvist said: > Hi > > I have a question about threads. I was wondering about what realy > happens to a thread on the OS level when i set it to read from a socket > when there is no data there. I use Native threads (not green threads). > > Will the thread realy sleep, no contex switch will be done. The thread > will sleep until a the OS get a interruption from the NIC.
Well, sort of. The thread will sleep until the network stack gets data for that specific socket. (Or some other event for that socket like SIGPIPE, etc) Internally, the OS may get many hundreds of NIC interrupts for other data streams and networking events that have nothing to do with your socket read. Thus, there is no need to directly associate a NIC interrupt with the waking up of your thread. Also, a socket event could be caused by outside events (such as TCP/IP timeouts and teardowns) that are not caused by the NIC itself. > or will thread contex switching still be done to see if there is data to > be read. In the green-threads like environment, the actual code (JVM implementation) will just make sure that it is looking for an event on that socket and then let other code run. If no other code needs to run, it will "effectively" sleep on all of the file descriptors (see select()) but with some timer event to also support the wakeup of threads that may be sleeping with a timeout. The select() (or poll()) call does not return until some event takes place so it can handle a large number of pending I/O operations without much overhead. (Other than building the select()/poll() array of file descriptors that it is interested in.) > I have an application that should handle alot (>10 000) connection at > the same time but usally no traffic. Is the best way to make a thread > pool or is the best way to have 1 thread per connection. If no contex > switching will be done I don't see why not. Well, this is interesting - with lots of connections you may wish to use the new IO model that provides async connections. Not due to "performance" but more so due to "thread overhead". Each thread needs its own context and stack which means many bytes of address space if not actually mapped memory. Even if you could run with 8K of overhead, that makes for 80meg of overhead just for that. The reality is that the overhead is much more than 8K as there are other structures that need to be filled out. Depending on your code and the exact kernel version, the per thread overhead could be relatively high for something that could use >10,000 threads. Having said that, there are cases where using threads makes the code easier to maintain and the performance easier to scale when you move to multi-processor systems. You need to judge that for yourself. -- Michael Sinz Technology and Engineering Director/Consultant "Starting Startups" mailto:[EMAIL PROTECTED] My place on the web http://www.sinz.org/Michael.Sinz ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
