Just to expand on the previous reply: a lot of C libraries have a blocking model where you call a function that blocks until it is complete.  The simplest example is fread().  If the interpreter doesn't support multiple threads, you have to do a lot of gymnastics to make sure you never block the interpreter in an extension.<p>It can be done (this is how Ruby pre-1.9 works), but people complain about it a lot.  Matz's rationale for why he added native OS threads to Ruby 1.9 was "people seem to like them."<p>In response to my fread() example you may be tempted to say that you can just put the underlying fd in non-blocking mode with fcntl(2).  This is unfortunately unsafe (as I recall), though I cannot find the reference right now.  Accessing the fd directly with read() and write() is non-blocking mode is of course safe, but then you have to do your own buffering.<p>Also, while poll() and select() give you most of what you need to make your I/O non-blocking, I recall a case where a pipe will be write-ready, but if you try to write too much data at the same time the write will block anyway, instead of returning a short count of bytes written.  This was on RHEL3 Linux, so things may have changed since then.