I'd really be a fan of any alternative approach to the current boilerplate; even hidden behind a macro I still feel gross even knowing that it's there.
On Tue, Oct 23, 2012 at 7:31 PM, Niko Matsakis <[email protected]> wrote: > On the topic of TLS boilerplate: > > At some point it was proposed that we use the type descriptor itself as > the key. With some minimal effort, we could make them unique, at least for > nominal types---TLS could just fail if a non-nominal type were used as the > value, or perhaps we can enforce this statically through a kind. That > would eliminate the boilerplate of using TLS, basically. You'd just have > to declare the struct/enum type that will serve as the value. I like this > idea. > > > Niko > > Graydon Hoare <[email protected]> > October 23, 2012 1:19 PM > > Probably. I believe it wasn't done that way for two reasons: > > - Data addresses can be recycled by accident, due to stack/heap > reuse. Code segment addresses are Really Unique at load time. > > - TLS needs function pointers anyways to have cleanups associated > with TLS entries when tasks die. > > It might be possible to merge these a bit more (there are unfortunate > linkage complications with PLTs anyways) but in general I expect to hide > whatever boilerplate there is behind an item macro like: > > condition! missing_file(&Path) -> Reader; > > -Graydon > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > David Rajchenbach-Teller <[email protected]> > October 23, 2012 8:14 AM > > Couldn't |missing_file| itself be the TLS key? > > Cheers, > David > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > Daniel Patterson <[email protected]> > October 23, 2012 8:12 AM > > TLS storage needs a unique key to identify it. Right now, the way that is > done, as I understand it, is with the memory location for a global > function. So this is truly boilerplate, just a way to get a unique > identifier for the storage. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > David Rajchenbach-Teller <[email protected]> > October 23, 2012 8:00 AM > > On 10/23/12 3:44 AM, Graydon Hoare wrote: > > On 12-10-21 09:50 PM, Benjamin Striegel wrote: > > If it's not too much trouble, a complete example (using any one of the > proposed syntaxes) would be enlightening. I'm still having a hard time > imagining how OutOfKittens is defined, and how do_some_stuff et al > signal it in the first place, and how the input/output of OutOfKittens > can be utilized within the signalling function. > > Sure. Let's use a real case such as "trying to open a file that might be > missing in the middle of a call to read_whole_file_str". This involves a > few assumed changes to the way io is structured, but nothing deep: > > // Boilerplate for declaring TLS key > fn missing_file_key(_x: @Handler<Path,Reader>) { } > > I do not understand this line. > > > const missing_file : Condition<Path,Reader> = > Condition { key: missing_file_key }; > > I have a little trouble parsing this line in which Condition appears > both as a type name and as a constructor. Nothing fatal, but it might be > a little difficult on end users. > > > mod io { > > [...] > > } > > Clear enough? > > Looks good to me, and I appreciate the demonstration that we can > effectively write the definition of handlers after the protected code, > at least as a coding convention. > > Cheers, > David > > > _______________________________________________ > Rust-dev mailing > [email protected]https://mail.mozilla.org/listinfo/rust-dev > > Graydon Hoare <[email protected]> > October 22, 2012 5:44 PM > > Sure. Let's use a real case such as "trying to open a file that might be > missing in the middle of a call to read_whole_file_str". This involves a > few assumed changes to the way io is structured, but nothing deep: > > // Boilerplate for declaring TLS key > fn missing_file_key(_x: @Handler<Path,Reader>) { } > > const missing_file : Condition<Path,Reader> = > Condition { key: missing_file_key }; > > mod io { > // Revised to not use Result anymore > pub fn file_reader(path: &Path) -> Reader { > let f = do os::as_c_charp(path.to_str()) |p| { > do os::as_c_charp("r") |m| { > libc::fopen(p, m) > } > }; > if f as uint == 0u { > // No such file; ask for help via .raise > missing_file.raise(path) > } else { > FILE_reader(f, true)) > } > } > } > > fn main() { > do missing_file.trap(|_p| > BytesReader { bytes: ~[], pos: 0u } as Reader > ).in { > // This will trap in io::file_reader and > // substitute the empty bytes_reader above > let s = io::read_whole_file_str(Path("/nonexistent")); > } > } > > Clear enough? > > -Graydon > > _______________________________________________ > 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 > >
<<compose-unknown-contact.jpg>>
<<postbox-contact.jpg>>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
