chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Evan Hanson
Subject: Re: [Chicken-users] Questions/nitpicks about Posix I/O
Date: Fri, 06 Sep 2013 17:56:38 +1200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8

On 06/09/13 16:48, Matt Gushee wrote:
> I need to open an output file in append mode. Since none of the
> high-level I/O functions appear to allow this, it seems I need to use
> the posix library.

Without digging any further, I'd point out that `with-output-to-file` et
al. also accept #:append (as with `open-output-file`, which you mention
but don't use in your example), since this is something really handy
that I wasn't aware of for a long time.

So, maybe your problem is solved by simply doing the following?

    (with-output-to-file "somefile.txt"
     (lambda () (display <some-text>))
     #:append)

I agree with the rest of your email re: the posix API. I usually have
to trawl mailing list for examples whenever I need to do anything
involving fds or pipes.

1-4 and 7-9 all seem like the ideal behavior to me.

5 is confusing, and I agree that it should be an error (as in 4).

On my machine, 6 is only true until you flush or close the second port,
at which point its output is produced. I don't think this should be an
error.

Regarding names, at first glance `fileno->output-port` seems more clear
to me than `open-output-file*`, although neither name really helps to
signal any of the limitations you listed. However, you say that...

> [open-output-file*] does nothing to change the state of the file
> object, it simply makes it available for high-level output procedures.

... But that's only true until you close that port, at which point it
*does* change the fd (since no more ports may be opened for it). To me,
it would be ideal if closing that fd was delayed until all associated
ports were also closed, but that may be hard/impossible/stupid for some
reason.

More generally, I find it easier to avoid opening more than one output
port for a given fd, and instead use higher level code to manage IO on
that one port (with custom/broadcast/concatenated ports, etc. for
fancier stuff). This skips most of the posix API altogether, and avoids
a lot of the issues you listed (hopefully... YMMV). Perhaps this pattern
could/should be enforced in the posix unit itself, by simply disallowing
multiple calls to `open-output-file*`s on a single fd?

Evan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]