[gambit-list] detecting closed ports

Dimitris Vyzovitis vyzo at hackzen.org
Sat Mar 24 11:13:18 EDT 2018


I settled for the following implementation, which is spec compliant:
https://github.com/vyzo/gerbil/blob/master/src/lang/scheme/base-ports.ss#L88

It first checks the roptions/woptions with macro-closed?, and then if it is
a device port it checks the read/write_stage.
It doesn't understand permanent-close, but the spec only requires that
close-* has been called on the port and has no notion of either threads or
non-permenantly closed ports.

-- vyzo

On Sat, Mar 24, 2018 at 2:25 PM, Dimitris Vyzovitis <vyzo at hackzen.org>
wrote:

> What about using the port roptions/woptions in conjunction with the
> permanent-close property?
> This could work for u8vector/string/vector ports, but I don't know about
> pipes.
>
> -- vyzo
>
> On Sat, Mar 24, 2018 at 1:59 PM, Dimitris Vyzovitis <vyzo at hackzen.org>
> wrote:
>
>> that's a very good point, i keep forgetting about the non-permanent
>> closure of pipes and its usability.
>> snarfing the read/write stage from the device may be ok, although we
>> won't be able to tell for pure scheme ports.
>>
>> -- vyzo
>>
>> On Sat, Mar 24, 2018 at 1:56 PM, Marc Feeley <feeley at iro.umontreal.ca>
>> wrote:
>>
>>> Knowing that close-port was called on a port is not sufficient to tell
>>> if the port is “closed” or not.  Apart from what it means for a port to be
>>> “closed”, there are ports that don’t close permanently when close-port is
>>> called on them.  See the example below of a pipe used for the communication
>>> between two threads.  It allows using close-port to send an “end-of-file”
>>> to the other thread multiple times.
>>>
>>> For “device” ports however, there is a state in the port object at the C
>>> level.  The fields read_stage and write_stage will be different from
>>> ___STAGE_OPEN when the device port no longer accepts reading or writing.
>>> Perhaps that is the information you want.  Note that not all ports are
>>> device ports.
>>>
>>> Marc
>>>
>>>
>>> (define in #f)
>>> (define out #f)
>>>
>>> (receive (i o) (open-string-pipe (list permanent-close: #f))
>>>   (set! in i)
>>>   (set! out o))
>>>
>>> (define (send x)
>>>   (write x out)
>>>   (newline out)
>>>   (force-output out)
>>>   (thread-sleep! 0.5))
>>>
>>> (define (close)
>>>   (close-output-port out)
>>>   (thread-sleep! 0.5))
>>>
>>> (thread-start!
>>>  (make-thread
>>>   (lambda ()
>>>     (let loop ()
>>>       (let ((x (read in)))
>>>         (pp x)
>>>         (loop))))))
>>>
>>> (send '(11))
>>> (send '(22))
>>>
>>> (close)
>>>
>>> (send '(33))
>>> (send '(44))
>>>
>>> (close)
>>> (close)
>>>
>>> (send '(55))
>>>
>>> ;; output:
>>> ;; (11)
>>> ;; (22)
>>> ;; #!eof
>>> ;; (33)
>>> ;; (44)
>>> ;; #!eof
>>> ;; #!eof
>>> ;; (55)
>>>
>>>
>>> > On Mar 24, 2018, at 5:51 AM, Dimitris Vyzovitis <vyzo at hackzen.org>
>>> wrote:
>>> >
>>> > You can't tell if a file descriptor is closed in general, that's not
>>> what I am after.
>>> > I just want to know if close-port was applied to the port.
>>> >
>>> > -- vyzo
>>> >
>>> > On Sat, Mar 24, 2018 at 11:43 AM, Adam <adam.mlmb at gmail.com> wrote:
>>> > The BSD/unix API does not allow this for TCP sockets, as in tapping
>>> into the OS' knowledge of whether a connection was closed, the only way to
>>> learn that is by trying to write to it.
>>> >
>>> > However with respect to Gambit knowing whether |close-port| was
>>> applied on a port, of course you should be able to retrieve that.
>>> >
>>> > 2018-03-24 16:29 GMT+08:00 Dimitris Vyzovitis <vyzo at hackzen.org>:
>>> > Is there a reasonable way to detect whether a port has been closed?
>>> > I want to implement input-port-open? and output-port-open? for r7rs
>>> coverage...
>>> >
>>> > -- vyzo
>>> >
>>> > _______________________________________________
>>> > Gambit-list mailing list
>>> > Gambit-list at iro.umontreal.ca
>>> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>>> >
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20180324/eea32f3b/attachment.htm>


More information about the Gambit-list mailing list