First-time read (or not, but even so I can't recall anything specific
from previous reads). Sorry if some of these have been debated before.

Specification
-------------

"A Scheme implementation that supports both this SRFI and multiple
threads of control must ensure that when a thread invokes a blocking
I/O procedure defined below, only that thread is blocked and not any
other concurrently running ones. Because Scheme threads may be
multiplexed on top of POSIX threads, the per-thread POSIX functions
may not do the right thing. "

I got confused after the second sentence introduces Scheme threads vs
POSIX threads. Which are the threads in the first sentence then? I
assume Scheme, but it's probably best to clarify it in the document.

3.3 I/O
-------

"you wouldn't be able to close file descriptor 3 unless there were no
3's in the system"

This doesn't read right to me, is it "unless" or "if". Or "no 3" is
short for "number 2"?

Should we say anything about making a port from a _directory_ fd?
There are some use for that in POSIX, but it's definitely not readable
(and absolutely not writable).

3.3 Filesystem
--------------

"It is an error to try to create a hard link when old-fname and
new-fname refer to the same file, and your file may be destroyed. "

Why is this error case singled out in the spec? There are a lot of
ways to go wrong with link() (or any POSIX functions for that matter).
I thought we would just leave it for POSIX to describe (or for users
to learn at their own cost).

"This procedure deletes directories from the file system. It is an
error if fname is not a directory or is not empty. "

could be "This procedure deletes an empty directory from the file system"

" This procedure follows symlinks and changes the files to which they refer. "

I feel this should be somewhere at the top of the spec. That is
"symlinks are followed unless otherwise noted". Or just drop it and
let the user read POSIX.

Also should set-file-owner take a port? There's fchown for that.
There's also fchmod.

On read-directory, too bad dirent's d_type is not POSIX even though
Linux and all major BSDs support it, as it would help reduce syscalls
quite a lot...

On temp-file-prefix, should we make an exception for Windows here? I
suppose when TMPDIR is not set, then it's better to use whatever
default temp dir on Windows instead of /tmp (or whatever system
tmpdir, if you want to avoid mentioning Windows at all)

I have an uneasy feeling about call-with-temporary-filename treating
_any_ exception as "file exists". Unrelated (and unexpected) errors
could also raise an exception and be misinterpteted as "file exist".
"maker" should behave more like a predicate and leave exception
handling to the user.

3.5 Process State
-----------------

About the use of "!" in procedure names, "nice" is also about side
effects, why isn't it be "set-nice!" too? Or should umask optionally
take a parameter which sets umake.

3.6  User and group database access
-----------------------------------

"Windows returns #f for any items it doesn't have."

maybe rephase it to something along the line of "unsupported items return #f"

3.11  Environment variables
---------------------------

The concurrency note is interesting. Can we just state that all
procedures in this srfi are thread safe on implementations that
support threads?

3.12  Terminal device control
-----------------------------

I wonder if the procedure name should be terminal-port? instead of
terminal? It's clearer and I doubt people would need to type this a
lot to matter.
--
Duy