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@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@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@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@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@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@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@iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
>