Email list hosting service & mailing list manager

socket-port Sven Hartrumpf (18 Jun 2013 06:38 UTC)
Re: socket-port John Cowan (18 Jun 2013 18:26 UTC)
Re: socket-port Takashi Kato (18 Jun 2013 19:09 UTC)
Re: socket-port Shiro Kawai (18 Jun 2013 21:40 UTC)
(missing)
Re: socket-port Shiro Kawai (18 Jun 2013 21:54 UTC)
Re: socket-port Alex Shinn (19 Jun 2013 00:51 UTC)
Re: socket-port Takashi Kato (19 Jun 2013 20:07 UTC)
Re: socket-port Shiro Kawai (20 Jun 2013 17:30 UTC)

Re: socket-port Shiro Kawai 18 Jun 2013 21:11 UTC

>From: Takashi Kato <xxxxxx@ymail.com>
Subject: Re: socket-port
Date: Tue, 18 Jun 2013 21:03:24 +0200

> I simply didn't consider non-R6RS implementations but if socket-ports
> returns 2 ports how could it be safely implemented? If the ports share
> the same socket descriptor then closing one port might cause SIGPIPE
> or something on the other port. (Might be too much detail but just
> popped up in my mind.)

Your logic is correct, so, in Gauche, closing one of the socket ports
does not close the socket descriptor (it does mark the Scheme-level
port structure as 'closed', and it does flush the output port).

I think returning a bidirectional port make things simpler.  Trade-off
is adoption of this srfi by implementations that doesn't have
bidirectional ports.  I'm ambivalent now; it's not hard to add
bidirectional ports to Gauche (and if R7RS-large defines it, I sure will.)
So I don't object the current spec as is.  But I wonder what other
implementors do.

BTW, it hits me that the srfi may need to describe what happens to a
socket when you close the socket port, and what happens to a socket
port when the socket is closed.

--shiro