On Mon, Oct 04, 2004 at 05:37:20AM +0900, James Edward Gray II scribed: > I've not used Ruby's threads before, so I have what will probably be > some basic questions. I'm pretty familiar with using native thread > systems, but these "in processor" threads raise some questions for me. > > I'm especially wondering about IO. I've read that Ruby's threads can > be dangerous when making possibly lengthy calls to the operating > system. How does that affect threaded servers in Ruby? If you call > gets() on a socket, does the program hang until that socket produces > input containing a \n character? If so, what's the best solution? Use > non-blocking IO techniques? > > I guess that's a pretty specific example and I am interested in the > affects of this type of threading on networking code, but let me ask > something more general. When should I be stopping to worry if this > action I'm threading will stall the whole program? Where is this > generally a problem? Ruby's threads seem "generally pretty good" about not blocking on IO calls _if_ you do them right. An example from a program I was working on: mybuf.sbuf += s.sysread(65536) vs mybuf.sbuf += s.sysread(4096) The former caused (all of) Ruby to block. The latter was handled properly. I _assume_, but didn't verify, that this is because Ruby was doing something like select() read(foo) internally, and the read with the huge blocksize scrogged things by blocking anyway. But I was being stupidly lazy trying to sysread such a large blocksize anyway ... is/was this a Ruby bug? Perhaps. But easily worked around. In _general_, you shouldn't have to use nonblocking IO, but there are likely operations that Ruby can't make internally nonblocking. DNS lookups are often a pain to perform asynchronously unless you explicitly use an async DNS library, for instance. File operations over NFS can block and are next to impossible to deal with without either multiple processes or kernel-level multithreading (particularly metadata operations like lookup and open). -Dave -- work: dga / lcs.mit.edu me: dga / pobox.com MIT Laboratory for Computer Science http://www.angio.net/