About three weeks ago, Matthew Flatt wrote:
> At Wed, 7 May 2014 12:07:28 -0400, Eli Barzilay wrote:
> > Two hours ago, Matthew Flatt wrote:
> > > I've added `custodian-tidy-all` and related functions to
> > > [un]register a "tidy callback".
> >
> > I was curious how it works, and on a quick look it sounded like
> > there's a potential problem if a sandbox is registering a bad tidier.
>
> Oh, I see what you mean. The current design is wrong.
>
> In adding this functionality, I wondered whether the job really
> belongs with custodians...
>
> More generally, I had the wrong idea at the start. I initially
> thought that these callbacks were a kind of must-do-on-exit
> action. If that were the case, then the custodian hierarchy would
> help ensure that the callbacks are actually called. Consistent with
> that misunderstanding, I called the new functionality "exit"
> callbacks, at first.
>
> But now I understand the new functionality as optional callbacks
> that don't "exit" anything. They try to put things into a nice
> state; that's a good thing to do just before exiting, but it can
> make sense at other times, too. Besides being not mandatory
> (anything mandatory has to be in the privileged world of custodian
> shut-down actions), they could use a slightly different hierarchy
> than custodians.
FWIW, I thought that because the tidier design was leaving it possible
for custodian to avoid tidying, which made it all fine eventually.
But the new thing makes more sense with a custodian shutdown becoming
the equivalent of a "terminated forcibly" as in a unix kill -9.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
____________________
Racket Users list:
http://lists.racket-lang.org/users
