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