On 11/21/11 7:34 PM, Graydon Hoare wrote: > On 19/11/2011 2:31 PM, David Rajchenbach-Teller wrote: > >> Let's switch vocabulary, then. "Report" and "Handle" are probably less >> loaded with implicit meanings. > > Sure. Those are good terms. So long as it's clear there are a few > dimensions to the issue: > > - What is checked statically (if at all) for exhaustiveness. > > - Whether you can recover at the reporting site or must always > unwind a bit (say, to the nearest handler). > > - Whether you permit unwinding at all. > > - Whether unwinding, once started, is permitted to stop before it > unwinds the whole task. > > - If you can stop (catch) an unwinding early, what the meaning of > that is in terms of the consistency or inconsistency of the local > heap. > > - How handlers are located and associated (globally, by dynamic scope, > by type, by static region, by task ownership, etc.)
Absolutely. >> Can I assume that your example is actually too short to demonstrate the >> meaningful difference with C++/ML-style exceptions and that the >> following would also work? > > I think the example I gave was long enough, but I guess it depends how > you look at it. The salient point is that recovery happens w/o > unwinding. The dynamic scope is *searched* to find a handler, but the > handler is invoked w/o any unwinding, and since the handler succeeds > (executes a 'ret', returning a value to the reporting site) execution > continues at the reporting site. No unwinding occurs. Ah, I had missed the dynamic scoping, thanks for pointing this out. > Spawning a task is going to be more expensive than a C++ try-protected > block; there's a private heap and private scheduling (failure is async > relative to the execution of the parent). > > I can't pretend the costs are equivalent. It'll be more expensive. But > the intent was for that expense to be the price paid for more-useful > isolation: IME most C++ try-protected blocks fail to actually contain > their error, because the heap is corrupted on the way out. Really? I was not aware of this. How is it corrupted? Do I understand that, a try-catch scenario, the main interest of using a task instead of the C++ model is to protect the heap? > Aside from the cost angle, yes, I think given an implementation of 'any' > and the appropriate failure-message-conveyance on task failure, we'll > have something that behaves similar to C++ exceptions, but with task > isolation -- more-proper containment. That's why I chimed in initially > on this thread saying "we already have exceptions". That much is on the > drawing board. > > IMO this thread is about whether we need something else, in addition, > that *is* as cheap as C++ try-protected blocks, and possibly does > finer-grained recovery (in terms of language abstractions employed). To > me that's not clear yet, and I'm suggesting we err on the side of not > providing it and seeing how the existing abstractions hold up. Well, the initial thread was about writing a nice I/O library and, in particular, how Reporting should be designed. I admit that, for the moment, I do not see any good way of using either pass-flags-in or signals-and-handlers in any meaningful manner in that specific scenario. > >> And in that case, I have some difficulty finding out exactly which case >> remain to be covered by the library design you detail above. >> >> Could you provide a few examples before I answer the following? > > Which, the pass-flags-in approach, or reviving the older design for > signals-and-handlers? I was thinking about pass-flags-in, but actually both would be nice. I have toyed with both on paper and, at the moment, my personal impression is that neither mechanism is particularly useful. Both seem to allow recovery only from the most trivial mistakes, and both seem to require outside so much knowledge of the internals of the function that the only uses I can see are purely local, in wrapper functions co-developed with the function that may Report. I suspect that you have a different impression/experience, so please do not hesitate to convince me :) Thanks, David
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
