thread i/o

From: Michael Hicks (mwh@dsl.cis.upenn.edu)
Date: Tue Jan 12 1999 - 21:12:32 MET

From: Michael Hicks <mwh@dsl.cis.upenn.edu>
Message-Id: <199901122012.PAA16699@codex.cis.upenn.edu>
Subject: thread i/o
To: caml-list@inria.fr
Date: Tue, 12 Jan 1999 15:12:32 -0500 (EST)

One of the adverisements of OCaml 2.01 was that user-level (not POSIX)
thread I/O is made faster. The trick used in the implementation is to make
sockets non-blocking, and then only perform a select() when the I/O would
have blocked (by signalling EINTR or EWOULDBLOCK). However, looking at the
implementation, it looks like in many cases the select() is performed
anyway. Here is an excerpt from threadUnix.ml:

let rec read fd buff ofs len =
  Thread.wait_read fd;
  try Unix.read fd buff ofs len
  with Unix_error((EAGAIN | EWOULDBLOCK), _, _) -> read fd buff ofs len

The implementation of Thread.wait_read and Thread.wait_write will perform
either a select() or go through the scheduler which will perform the
select(). It seems to me that the implementation should be:

let rec read fd buff ofs len =
  try Unix.read fd buff ofs len
  with Unix_error((EAGAIN | EWOULDBLOCK), _, _) ->
    begin
      Thread.wait_read fd;
      read fd buff ofs len
    end

This way, if I/O is already available, there is no need to do the extra
select(). Am I missing something?
Mike 

-- 
Michael Hicks
Ph.D. Candidate, the University of Pennsylvania
http://www.cis.upenn.edu/~mwh            mailto://mwh@dsl.cis.upenn.edu
"I worked with an individual who plugged his power strip back into itself
and for the life of him could not understand why his computer would not
turn on."

This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:17 MET