[racket] Callback on shutdown

I've added `custodian-tidy-all` and related functions to [un]register a
"tidy callback". The default exit handler calls `custodian-tidy-all` on
the root custodian before exiting, which triggers all registered tidy
callbacks.

I found one place where I needed this before: `reencode-output-port`. A
port produced by `reencode-output-port` now installs a tidy handler to
flush output whenever its buffer is non-empty. Setting the current
output port to a reencoded port now flushes in the way you'd expect on
exit.

At Sun, 4 May 2014 17:02:59 -0600, Matthew Flatt wrote:
> I don't think the thing you want currently exists in general, although
> it exists internally for flushing output ports.
> 
> Simply triggering the exit handler when the Racket process exits
> doesn't seem like a good enough solution. It's awkward to add and
> remove callbacks by changing the exit handler, and it doesn't
> immediately address the problem of exiting sandbox-like nested
> processes. I don't have a solution that immediately addresses the
> problem of subprocesses, but if we have to revise sandbox-like things
> to support a polite exit, then I think we can find a better interface.
> 
> Maybe the right solution is to add support for atexit()-like actions on
> custodians, along with a new operation to exit a custodian (implying an
> exit for all sub-custodians). Various exit modes, including normal exit
> of the Racket process or calling the default exit handler, would use
> the custodian-exit operation before existing. Sandboxing contexts can
> be similarly improved to exit a custodian or add support for exiting,
> depending on what makes sense for the context.
> 
> Unlike shutting down a custodian, which is analogous to SIGKILL,
> exiting a custodian would be closer to SIGQUIT. Along those lines,
> where shutting down a custodian implies mandatory and atomic actions,
> exiting a custodian is a request and non-atomic --- so it would safe to
> attach arbitrary exit procedures. Of course, there's no guarantee that
> an exit procedure will be called if a custodian is first shut down.
> 
> I'm not sure why we haven't particularly needed this before, except in
> the built-in case of flushing output ports. It's interesting that your
> context is also about flushing.
> 
> At Sun, 04 May 2014 16:19:37 -0400, Tony Garnock-Jones wrote:
> > On 05/04/2014 04:11 PM, Robby Findler wrote:
> > > Sounds to me like you want to wire into the custodian facilities (via
> > > the ffi I believe) but probably starting with just atexit() itself is
> > > okay.
> > 
> > Via the FFI! Gosh. That sounds scary.
> > 
> > I did try register-custodian-shutdown from ffi/unsafe/custodian, but (a)
> > it wasn't called when the program exited normally, and (b) when I called
> > (custodian-shutdown (current-custodian)), it complained about a blocking
> > operation in atomic mode or something like that, and abort()ed. I then
> > explored use of exit-handler instead :-)
> > 
> > Would it make sense to change Racket to ensure the current exit-handler
> > is called at the end of the main program?
> > 
> > Regards,
> >   Tony
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users