   blocking vs non blocking io controversy...
  Hey all:question:I''m looking at building or using a core networking library that I want to be re usable. The question is should I use blocking or non blocking I/O? I''m torn between the 2, because they both offer distinct advantages...non blocking IO is cool because all the read/write stuff can be done in a single thread. I like this idea because my 3d engine is not multi threaded, so it means I could just plop the network module into my system without a lot of issues.(I choose a single threaded implementation to avoid the performance penalties associated w/ context switching and mutexs..It also makes the code much much simpler since it eliminates a bunch of potential for nasty crap like deadlock race conditions and non mutually exclusion)I like the blocking IO model because it relies on spawning threads for new processes. This is an elegant solution to program, although it carries some performance penalties when the number of sockets open reaches a certain point.So I''m not sure...I''m torn. I would rather have the network design be more complicated if it means the 3d engine relying on it can be kept somewhat simpler. I''d like to hear from some people with some experience in this dept, prefereably with an objective look at both strategies...Thanks all!your pal, Neko   
  I''d suggest non-blocking I/O.When there is only blocking I/O (such as file access on Windows 98/ME), I end up writing my own non-blocking I/O API, which is implemented using threads on the inside, but looks non-blocking to the rest of the program.;  If you can afford the performace penalty associated with a thread per client, blocking IO does simplify your state maintainance.A protocol in a "thread per client" is a lot simpler to write in blocking fashion...//pseudo-code beginnetwork.read(&buffer)if(buffer != HELLO_HANDSHAKE) network.drop();do {   network.read(&buffer);   switch(buffer[0]) { case POSITION_UPDATE:    //process update    break; case BULLET_FIRED:    //process bullet fired    break; //etc...   }} while(buffer != GOODBYE)... but then of course you have to manage shared memory across threads. Still, using a shared msg. queue between client threads and main thread simplifies this task immensely (as opposed to protecting each major element on its own), so the task is doable.Best regardsBjørn Toft Madsen ;quote:...relies on spawning threads for new processes. This is an elegant solution to program, although it carries some performance penalties when the number of sockets open reaches a certain point.It''s no more elegant than a well-designed single threaded approach.quote:If you can afford the performace penalty associated with a thread per client, blocking IO does simplify your state maintainance.Blocking IO can be a fine approach that doesn''t inherently require threading.  Unfortunately the original poster used the magic word: "reusable".  The thread-per-client approach doesn''t offer the scalability that a generic, reusable networking library should provide.For a generic, reusable library, I''d suggest nonblocking IO that does not implement threading internally.  The idea is to create an interface such that the specific application can manage threading according to their own model, not be forced into a particular model inherently by your network library.  This approach is simple to debug, and is easier for application programmers to include ''transparently'' into their specific app.  Good luck.    ;  The expressive power of non-blocking is higher than that of blocking.Given a non-blocking API, that has the capability of waiting on some list of sockets for incoming data (such as select()), you can easily use that in a blocking fashion using a very thin wrapper.Given a blocking API, there''s no way of using that in a non-blocking fashion without really crufty threading wrappers, and those wrappers will severely limit your scalability. 