Do custodians shutdown when Racket exits?

[David Storrs]

A bunch of reading through docs suggests that custodians do not automatically run when Racket exits and that if I want them to then I should either use a plumber (which is not guaranteed to run if there's a segfault) or register the custodian with the ffi/unsafe/custodian module (http://web.mit.edu/racket_v612/amd64_ubuntu1404/racket/doc/foreign/Custodian_Shutdown_Registration.html)  Is that right, or is there something I'm missing?

[David Storrs]

I should mention that the reason I'm looking into this is because I have UDP sockets that are not getting closed.  They are managed by custodians, but the custodians are not releasing them; I take this to mean that the custodians are not being run.

[Sorawee Porncharoenwase]

I have a similar question on will executor. It doesn't seem to get run on program exiting/breaking. Do I need a plumber that calls `collect-garbage`?

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKofYd5Uv4JWCbwjrHnmJuc%3DV%2BjVHWTwRxB9kdF1LsinEKg%40mail.gmail.com.

[Tony Garnock-Jones]

On Tuesday, August 6, 2019 at 6:27:51 PM UTC+1, David Storrs wrote:

I should mention that the reason I'm looking into this is because I have UDP sockets that are not getting closed.  They are managed by custodians, but the custodians are not releasing them; I take this to mean that the custodians are not being run.

How can a UDP socket survive process exit?

Tony

[James Platt]

On Aug 6, 2019, at 1:54 PM, Tony Garnock-Jones wrote:

> How can a UDP socket survive process exit?
>

I don't knot but this appears to happen. On macOS, the open port shows in netstat but not lsof. You can find the process ID with netstat but then, when you go to kill it, kill says there is no such process. The important this is, of course, that trying to run another process with that port will fail.


Note that netstat on macOS does not have all the same command flags as the Linux version but you can see pids using:
netstat -anv


James

[George Neuner]

Sockets belonging to the crashed program are in a "half-closed" state - unable to send, but still able to receive.  If you look in netstat you'll find their status is stuck in TIME_WAIT or in SYN or SYN/ACK.  There is a delay in cleaning up such "half-closed" sockets.  The delay is (derived from) a system wide parameter, and typically the wait time is on the order of 180 seconds.

For most sockets it doesn't matter, but for a receiving "listen" socket,  you need to set the  SO_REUSEADDR  option to be able to reuse the same ipaddr:port combination again without waiting for cleanup.  SO_REUSEADDR  doesn't actually change the system's cleanup behavior - it simply says that the system can ignore "already exists" errors when trying to create a new socket.


That said ... I thought Racket set  SO_REUSEADDR  automagically when you create listen sockets.

George

[Tony Garnock-Jones]

On Tue, 6 Aug 2019 at 21:15, George Neuner <gneu...@comcast.net> wrote:

Sockets belonging to the crashed program are in a "half-closed" state - unable to send, but still able to receive.  If you look in netstat you'll find their status is stuck in TIME_WAIT or in SYN or SYN/ACK.  There is a delay in cleaning up such "half-closed" sockets.  The delay is (derived from) a system wide parameter, and typically the wait time is on the order of 180 seconds.

Those states only apply to TCP sockets; UDP is stateless (in that way). It still seems quite peculiar to me that UDP sockets should outlive their process, under any circumstances. Perhaps it's a Mac-specific thing? I wonder if it's a bug or if it's for some reason.

Tony

[George Neuner]

That's not exactly true - UDP is "stateless" only when compared to streams.

The datagram protocol is itself a state machine, and there are a number of modes that UDP sockets can be in, including "half-closed":  e.g., you can call shutdown on a UDP socket to individually block either its send or receive capabilities.  Also, you can call connect on a UDP socket and then use read, write, send and recv in lieu of the stateless sendto / sendmsg or recvfrom / recvmsg.  I.e. there is both the notion of "unconnected" and "connected" UDP, although "connected" means something different here than it does with TCP.

I've been programming so long that most of my sources are dead trees on a bookshelf.  Google is not being particularly helpful just now in finding a comprehensive socket reference to cite ... unless you want PDF books or the original RFCs.  It seems much of the online information on UDP  is in bits and pieces, and most of it deals only with "unconnected" use.  But you can search "connected udp" for a few starting points.

I'm not sure what, if anything, netstat can show for "connected" or "half-closed" UDP sockets -  I'm don't think network stack makes any of that information available to be queried.  It's much more concerned with the more complex TCP status.

George