Re: Input/output problems with closed ports

[Gary Houston <ghouston at freewire dot co dot uk>]

| How can you ensure it is legitimate to read from
| or write to a port object ? Doing so on a closed port raises an
| error with guile, which seems legitimate (though, 
| R5RS says so explicitely only for read, not read-char 
| and peek-char, and not for writing).
|
| This situation can be handled with using 
| catch and throw. But this technique works only at the time you
| perform the I/O, you cannot know the port status in advance.
| 
| The context where I encountered this problem was when dealing with sockets, to
| test if the remote link is still there.
| 
| So I would actually have a "closed?" function, and it seems missing in
| guile (have not looked elsewhere).

I don't think Guile on its own is ever going to close a port just
because of some kind of socket error.  Usually it works like this: if
the remote side has disconnected then attempting to read from the
socket will return data that has already been received by the kernel,
or an end-of-file object if there's nothing in the queue.  Attempting
to write to the socket will raise an error (perhaps after a delay if
the remote end can't be contacted at all.)  But not the same error 
that you get if you write to a closed port.

So as far as I can see, a closed? function isn't going to help.  In
any case it's not a good technique, since there's no way to be sure
that the remote end isn't going to fail between the time that you test
the connection and the time that you use it, or while it's in use.