Re: [Chicken-users] Questions/nitpicks about Posix I/O

[John Cowan]

Matt Gushee scripsit:

>   (let* ((f (file-open "somefile.txt" (+ open/wronly open/creat open/append)))
>             (p (open-output-file* f)))
>       (display <some-text> p)
>       (close-output-port p))

While this will work, it leaves the port (and the fd) dangling in case
of an exception, so it's better to wrap these in dynamic-wind and close
both p and f on the way out.

> First there is the apparent redundancy of (file-open ... open/append)
> vs. (open-output-file ... #:append).

The identifier open/append is just bound to an integer: the Posix API is
deliberately very close to its C equivalent.  It's the same as O_APPEND
from <fcntl.h>, and is normally, but not necessarily, 8.

> 1. If you create an fd with file-open, then create an
>    output port by applying open-output-file* to the
>    resulting fd, you can pass an append argument to
>    either function, or both; either way, both the fd
>    and the port are then set to append mode.

Correct, because it's really the fd that knows about append mode.

> 3. After one output port has been opened and closed, it is an
>    error to open another output port on the same fd.
> 
> 4. It is an error to write to an fd after the corresponding
>    port has been closed.

That's what you expect in both cases, because closing the port closes
the fd.

> 5. It is possible to write to a port after the corresponding
>    fd has been closed, but this does not produce any output.

That is surely a bug.

> 6. It is possible to open more than one output port on a
>    single fd, but only the first port produces any output.

That's an error that would be hard to catch, I think.  A fd is just
an integer, and we don't keep around a table of which ports have that
fd in them.  (Note that not all output ports *have* associated fds;
in particular, string ports don't.)

> 7. Given an fd F, it is possible to create a second fd G
>    using duplicate-fileno, then open output ports P and Q,
>    based on F and G respectively; both ports produce output.

Again as expected: the OS manages the interactions between the
two fds.

> 8. If you pass #:append to one of the output ports opened in
>    #7, that affects both fds and both ports.

The two fds are not really independent: in particular, they share
any locks, and it doesn't surprise me too much that they share the
same append flag.

> #7-9: It seems like generally a bad idea to open more than one fd on a
> single file. However, I took a look at the POSIX open() man page, and
> as far as I can tell this behavior is permitted.

Separate opens (as in #9) maintain separate current positions, which
can be handy when you need to read a file sequentially in more than one
place at a time.

-- 
We call nothing profound                        address@hidden
that is not wittily expressed.                  John Cowan
        --Northrop Frye (improved)