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 Takashi Kato 19 Jun 2013 20:01 UTC
On 18/06/2013 23:11, Shiro Kawai wrote: > So I don't object the current spec as is. But I wonder what other > implementors do. I think that's the whole point of 'socket-ports'. But I'm tending rather let implementation support bidirectional port. > 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. I was thinking (and reference implementations do) that when port is closed then it's cleanup the socket. But as you mentioned about multi process, it might not be a good idea. Chibi's style (specifying whether or not cleanup the socket on GC time or closing) seems reasonable to me. Now, think about multi process what should happen on GCing socket? (I'm not even sure how socket object can be passed to other process since the srfi doesn't have any way to create it passing fd though.) To me, it's reasonable to cleanup since no srfi nor standards mentions multi process, or is it better to be unspecified so that implementations have space to expand? _/_/ Takashi Kato E-mail: xxxxxx@ymail.com