Hello! @Clark: I must've hit reply instead of reply-all, thanks for re-adding rust-dev. I'm not sure I agree about the fail! thing. I think crashing a task on an unexpected condition is easier to code and to reason about. It forces me to think about recovery and atomicity. Also even if I structured my code to return option<> from every call site I'd still have the possibility of e.g. array out-of-bounds failures.
@Matthieu: Awesome thanks. When I get some time I need to dig into task internals and try to implement this. Thanks, Phil On Thu, Mar 27, 2014 at 5:19 PM, Matthieu Monrocq < [email protected]> wrote: > > > > On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel <[email protected]>wrote: > >> aside: Your last message didn't get CC'd to rust-dev. I've re-added them, >> and hope dearly I haven't committed a social faux pas. >> >> That's interesting. You're kinda looking for exception handling in rust! >> Unfortunately the language seems pretty principled in its opinion that >> failure should be handled at the task boundary exclusively, and this is a >> pretty heavyweight opinion. >> >> This wouldn't be so bad if people would stop fail!ing everywhere! I'm >> personally very against the seemingly growing trend of people doing things >> like calling unwrap() on options instead of propagating errors up. This >> makes accidental failure far, far more common than it should be. >> >> I hope when higher-kinded-types and unboxed closures land, people will >> start using a monadic interface to results and options, as this will >> hopefully make error propagation less painful. We'll see. >> >> As for your specific case, I don't really have an answer. Is "just don't >> call fail!" an option? Maybe an automatically-inferred #[will_not_fail] >> annotation has a place in the world... >> >> - Clark >> >> > Actually, there is nothing in the task model that prevents them from being > run "immediately" in the same OS thread, and on the same stack. It just is > an implementation detail. > > In the behavior, the main difference between try/catch in Java and a Task > in Rust is that a Task does not leave a half-corrupted environment when it > exits (because everything it interacted with dies with it). > > Implementation-wise, there may be some hurdles to get a "contiguous" task > as cheap as a try/catch: unwind boundary, detecting that the task is viable > for that optimization at the spawn point, etc... but I can think of nothing > that is absolutely incompatible. I would be happy for a more knowledgeable > person to chime in on this point. > > -- Matthieu > > > >> >> On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes <[email protected]>wrote: >> >>> Hi Clark, >>> >>> Thanks for the clarification. >>> To follow your example, there are multiple 'process_msg()' steps, and if >>> one fails I don't want it to take down the whole loop. >>> >>> Cheers, >>> >>> Phil >>> >>> >>> >>> On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel <[email protected]>wrote: >>> >>>> Sorry, was on my phone. Hopefully some sample code will better >>>> illustrate what I'm thinking: >>>> >>>> loop { >>>> let result : Result<Foo, ()> = task::try(proc() { >>>> loop { >>>> recv_msg(); // begin latency sensitive part >>>> process_msg(); >>>> send_msg (); // end latency sensitive part >>>> } >>>> }); >>>> >>>> if result.is_ok() { >>>> return result; >>>> } else { >>>> continue; >>>> } >>>> } >>>> >>>> This way, you only pay for the try if you have a failure (which should >>>> hopefully be infrequently), and you get nice task isolation! >>>> >>>> >>>> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel <[email protected]>wrote: >>>> >>>>> The "main loop" of your latency sensitive application. >>>>> On Mar 26, 2014 5:56 PM, "Phil Dawes" <[email protected]> wrote: >>>>> >>>>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Can't you put that outside your inner loop? >>>>>>> >>>>>> >>>>>> Sorry Clark, you've lost me. Which inner loop? >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Clark. >>>> >>>> Key ID : 0x78099922 >>>> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >>>> >>> >>> >> >> >> -- >> Clark. >> >> Key ID : 0x78099922 >> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
