From: Tanaka Akira <akr@...17n.org>
Date: 2006-05-21T12:10:31+09:00
Subject: Re: sysread changes behavior in the presence of threads?

In article <3a94cf510605201832g5a8d23cue1f0e2e69661d5f1@mail.gmail.com>,
  "Francis Cianfrocca" <garbagecat10@gmail.com> writes:

> I'd be inclined to categorize it as a bug. It violates the expectation that
> I/O is orthogonal to threads. I looked at the code in io.c and I can see the
> reason for it, but I'm writing a library and I don't have the luxury of
> making assumptions about whether there are other threads.

A workaround is Thread.exclusive { sd.sysread(4096) }.

However I think a nonblocking read method is right way to
fix this issue.  The problem is the method name, though.

There are several problems to fix sysread to cause EAGAIN in
I/O multiplex mode.  Since a nonblocking I/O doesn't block,
it is possible to avoid I/O multiplex to avoid entire
process blocking.  So if Ruby disables I/O multiplex for
nonblocking I/O, sysread will cause EAGAIN.  But,
unfortunately, Ruby cannot know nonblocking state of a fd in
some case.

1. Windows has no F_GETFL equivalent
  There is no way to know the state on Windows.

2. race condition
  Even on an environment which has F_GETFL, the state may be
  changed between F_GETFL and read(2) by another process.
-- 
Tanaka Akira