Re: [racket-users] Re: Do custodians shutdown when Racket exits?

[George Neuner]

On 8/8/2019 7:34 AM, Tony Garnock-Jones wrote:
On Tue, 6 Aug 2019 at 21:15, George Neuner > 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.


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

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/639b088b-ef38-bdf9-0302-96818dcf3bf9%40comcast.net.

Re: [racket-users] Re: Do custodians shutdown when Racket exits?

[Tony Garnock-Jones]

On Tue, 6 Aug 2019 at 21:15, George Neuner  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAM8fPiSHbQci6pw6UW4g27WRr6H7GNjjPTDEDmrp5mLXh2675A%40mail.gmail.com.

Re: [racket-users] Re: Do custodians shutdown when Racket exits?

[George Neuner]

On 8/6/2019 1:54 PM, Tony Garnock-Jones wrote:

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?


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

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c43bb573-9722-5a04-240a-004621ea96a5%40comcast.net.

Re: [racket-users] Re: Do custodians shutdown when Racket exits?

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/7EED97D1-B5AF-4DDF-A5D0-5E47314B04DF%40biomantica.com.

Re: [racket-users] Re: Do custodians shutdown when Racket exits?

[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`?

On Tue, Aug 6, 2019 at 10:27 AM 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.
>
> On Tue, Aug 6, 2019 at 1:06 PM David Storrs 
> wrote:
>
>> 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?
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAE8gKofYd5Uv4JWCbwjrHnmJuc%3DV%2BjVHWTwRxB9kdF1LsinEKg%40mail.gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CADcuegvhrpb-%2B%2BvJbEqLMOv%2B7Jz1sywkfjkfX9EbXcon7y3RAg%40mail.gmail.com.