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
Couldn't
|missing_file| itself be the TLS key?
Cheers,
David
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-devOn 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 list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
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
