[gambit-list] output ports created with ##open-predefined not being garbage collected
Marc Feeley
feeley at iro.umontreal.ca
Sat Apr 11 13:08:23 EDT 2020
> On Apr 11, 2020, at 1:01 PM, Jörg F. Wittenberger <Joerg.Wittenberger at softeyes.net> wrote:
>
> On Sat, 11 Apr 2020 09:30:30 -0400
> Marc Feeley <feeley at iro.umontreal.ca> wrote:
>
>>> My observation (on Linux) was that ##wait-input-port did not block
>>> the current thread at all. Thus gambit was sitting in a tight loop
>>> until data arrives.
>> ...
>> It should work. Can you show me a minimal version of your code?
>
> I shall destill. (Too much praise actually: gamsock is not really "my
> code".)
>
> Though while walking the dog it occured to me that the gamsock code
> reads the data directly from the file descriptor using recvfrom(2).
>
> It could have easily escaped me that the first attempt to
> ##wait-input-port did actually block. If there was the need to reset
> the port state (or go to the trouble to figure out how to change the
> heritage to read via gambit -- whatever is simpler) in order to inform
> the threading system that it should actually check the file descriptor
> again, then maybe we can shortcut the session.
>
> Best
>
> /Jörg
>
Are you communicating with UDP? If that is the case then maybe you can use Gambit’s UDP ports directly:
(open-udp port-number-or-address-or-settings)
This procedure opens a socket for doing network communication with the UDP protocol. The default value of the direction: setting is input-output, i.e. the Scheme program can send information and receive information on the socket. The sending direction can be closed using the close-output-port procedure and the receiving direction can be closed using the close-input-port procedure. The close-port procedure closes both directions.
The resulting port designates a UDP socket. Each call to read and udp-read-subu8vector causes the reception of a single datagram on the designated UDP socket, and each call to write and udp-write-subu8vector sends a single datagram. UDP ports are a direct subtype of object-ports (i.e. they are not character-ports) and read and write transfer u8vectors. If read is called and a timeout occurs before a datagram is transferred and the timeout thunk returns #f (see the procedure input-port-timeout-set!) then the end-of-file object is returned.
More information about the Gambit-list
mailing list