At Sat, 12 Mar 2016 15:35:14 -0500, Jon Zeppieri wrote: > I have TCP ports that I send from one place to another. I'd like the > receiving place to be responsible for closing them. In particular, I'd like > to make that the responsibility of a custodian in the receiving place. > > If I close the ports in the receiving place, however, that doesn't actually > close the underlying socket, because the sending place still has an open > file descriptor for it. And it seems that if I close the ports immediately > after sending them via `place-channel-put`, that's too soon. > > I could have the receiving place notify the sending one of receipt, at > which point the sender could close the ports -- I just tried this out, and > it works -- but that involves some undesirable bookkeeping overhead. > (Because I'm doing this in a loop, when I receive a message saying, "You > can close the ports now!" I need to keep track of exactly which set of > ports it's safe to close.) > > Is there a better way to handle this? Maybe the implementation of > place-channel-put could dup the file descriptor and then close the > duplicate after sending it?
Sending a file descriptor over a place channel does dup() it. Maybe you're seeing that closing a TCP output port sends an EOF to the other end. Does it help to use `tcp-abandon-port` in the original place instead of `close-output-port` (leaving the EOF-sending `close-output-port` to the receiving place)? -- 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. For more options, visit https://groups.google.com/d/optout.
