From: Reimer Behrends <behrends@...>
Date: 1998-12-22T23:43:02-05:00
Subject: [ruby-talk:00138] Thread Problems

I have been looking at the thread implementation of Ruby for the past
couple of days, and I think I may have found a few problems.

For instance, io.c does a lot of checking to see if a thread can block.
Unfortunately, some of these checks are incomplete. For example, if you run
the following script, the forked thread blocks everything else as soon as
you hit enter until you type Ctrl-D.

-----
fp = open("/dev/tty")

Thread.start do
  fp.read
end

while true do
  print "Looping.\n"
  sleep 2
end
-----

The reason is that there's only one check at the beginning of the
implementation of IO.read whether there is actual data, but no check if
there is sufficient data to satisfy the entire request. Similar problems
result on a number of other occasions, like when reading a locked file,
reading too much data from a pipe, etc.

An obvious solution would be to write custom implementations of read()
and write(), using, for instance, readv() and writev(). This would also
take care of library calls like fread() and fwrite(), except that you
then still end up with sticky reentrancy issues if libc isn't
threadsafe.

There isn't such an issue with sockets, as socket.c is written to make
use of non-blocking semantics.

Comments?

				Reimer Behrends

P.S.: Is there a reason why the current implementation is fixed at 10
      time slices a second? Most modern computers should be able to
      easily handle up to 10 times as much, even if you call select()
      each time.