Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Robert Goldman <rpgoldman@si...> - 2010-10-26 21:36:14
Sorry if this is an oddball question....
In previous correspondence on this list, there was some discussion of
CLOSE applied to socket streams:
2010/3/21 Lorenz Mösenlechner <moesenle@...>:
> > immediately. When the server tries to transmit data, a 'broken-pipe'
> > condition will be raised. It is not possible anymore to close the
> > stream because every close tries to flush the buffer, which again
> > results in the broken pipe error. The only possibility to close down
To close a stream without flushing, use
(close stream :abort t)
I was a little surprised by this.
When I look at the CLHS, I see
"If abort is true, an attempt is made to clean up any side effects of
having created stream. If stream performs output to a file that was
created when the stream was created, the file is deleted and any
previously existing file is not superseded."
The question I have arises from working on some polymorphic code where
we have a connection that might be to a socket for communicating
components or to a file.
We have found that it's necessary to close sockets without flushing,
because often normal closes error out. But we typically don't want to
blow away our files.
I can (and will) program around this, but I was wondering about the
interpretation of ABORT here. In one case it seems really drastic and
undo-like, and in the other it seems to simply be something more like
FORCE. Can anyone shed light on this?