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
