rust/src/libnative/io/timer_timerfd.rs, branch try

native: Remove timerfd implementation on linux

2014-04-12T20:42:07+00:00

Rust advertises itself as being compatible with linux 2.6.18, but the timerfd set of syscalls weren't added until linux 2.6.25. There is no real need for a specialized timer implementation beyond being a "little more accurate", but the select() implementation will suffice for now. If it is later deemed that an accurate timerfd implementation is needed, it can be added then through some method which will allow the standard distribution to continue to be compatible with 2.6.18 Closes #13447

std: Make std::comm return types consistent

2014-04-11T04:41:19+00:00

There are currently a number of return values from the std::comm methods, not all of which are necessarily completely expressive: Sender::try_send(t: T) -> bool This method currently doesn't transmit back the data `t` if the send fails due to the other end having disconnected. Additionally, this shares the name of the synchronous try_send method, but it differs in semantics in that it only has one failure case, not two (the buffer can never be full). SyncSender::try_send(t: T) -> TrySendResult This method accurately conveys all possible information, but it uses a custom type to the std::comm module with no convenience methods on it. Additionally, if you want to inspect the result you're forced to import something from `std::comm`. SyncSender::send_opt(t: T) -> Option This method uses Some(T) as an "error value" and None as a "success value", but almost all other uses of Option have Some/None the other way Receiver::try_recv(t: T) -> TryRecvResult Similarly to the synchronous try_send, this custom return type is lacking in terms of usability (no convenience methods). With this number of drawbacks in mind, I believed it was time to re-work the return types of these methods. The new API for the comm module is: Sender::send(t: T) -> () Sender::send_opt(t: T) -> Result<(), T> SyncSender::send(t: T) -> () SyncSender::send_opt(t: T) -> Result<(), T> SyncSender::try_send(t: T) -> Result<(), TrySendError> Receiver::recv() -> T Receiver::recv_opt() -> Result Receiver::try_recv() -> Result The notable changes made are: * Sender::try_send => Sender::send_opt. This renaming brings the semantics in line with the SyncSender::send_opt method. An asychronous send only has one failure case, unlike the synchronous try_send method which has two failure cases (full/disconnected). * Sender::send_opt returns the data back to the caller if the send is guaranteed to fail. This method previously returned `bool`, but then it was unable to retrieve the data if the data was guaranteed to fail to send. There is still a race such that when `Ok(())` is returned the data could still fail to be received, but that's inherent to an asynchronous channel. * Result is now the basis of all return values. This not only adds lots of convenience methods to all return values for free, but it also means that you can inspect the return values with no extra imports (Ok/Err are in the prelude). Additionally, it's now self documenting when something failed or not because the return value has "Err" in the name. Things I'm a little uneasy about: * The methods send_opt and recv_opt are not returning options, but rather results. I felt more strongly that Option was the wrong return type than the _opt prefix was wrong, and I coudn't think of a much better name for these methods. One possible way to think about them is to read the _opt suffix as "optionally". * Result is often better expressed as Option. This is only applicable to the recv_opt() method, but I thought it would be more consistent for everything to return Result rather than one method returning an Option. Despite my two reasons to feel uneasy, I feel much better about the consistency in return values at this point, and I think the only real open question is if there's a better suffix for {send,recv}_opt. Closes #11527

native: remove some internal ~[].

2014-04-10T22:21:58+00:00

Fix fallout from std::libc separation

2014-04-04T16:31:44+00:00

native: Switch field privacy as necessary

2014-03-31T22:47:35+00:00

log: Introduce liblog, the old std::logging

2014-03-16T05:26:36+00:00

This commit moves all logging out of the standard library into an external crate. This crate is the new crate which is responsible for all logging macros and logging implementation. A few reasons for this change are: * The crate map has always been a bit of a code smell among rust programs. It has difficulty being loaded on almost all platforms, and it's used almost exclusively for logging and only logging. Removing the crate map is one of the end goals of this movement. * The compiler has a fair bit of special support for logging. It has the __log_level() expression as well as generating a global word per module specifying the log level. This is unfairly favoring the built-in logging system, and is much better done purely in libraries instead of the compiler itself. * Initialization of logging is much easier to do if there is no reliance on a magical crate map being available to set module log levels. * If the logging library can be written outside of the standard library, there's no reason that it shouldn't be. It's likely that we're not going to build the highest quality logging library of all time, so third-party libraries should be able to provide just as high-quality logging systems as the default one provided in the rust distribution. With a migration such as this, the change does not come for free. There are some subtle changes in the behavior of liblog vs the previous logging macros: * The core change of this migration is that there is no longer a physical log-level per module. This concept is still emulated (it is quite useful), but there is now only a global log level, not a local one. This global log level is a reflection of the maximum of all log levels specified. The previously generated logging code looked like: if specified_level <= __module_log_level() { println!(...) } The newly generated code looks like: if specified_level <= ::log::LOG_LEVEL { if ::log::module_enabled(module_path!()) { println!(...) } } Notably, the first layer of checking is still intended to be "super fast" in that it's just a load of a global word and a compare. The second layer of checking is executed to determine if the current module does indeed have logging turned on. This means that if any module has a debug log level turned on, all modules with debug log levels get a little bit slower (they all do more expensive dynamic checks to determine if they're turned on or not). Semantically, this migration brings no change in this respect, but runtime-wise, this will have a perf impact on some code. * A `RUST_LOG=::help` directive will no longer print out a list of all modules that can be logged. This is because the crate map will no longer specify the log levels of all modules, so the list of modules is not known. Additionally, warnings can no longer be provided if a malformed logging directive was supplied. The new "hello world" for logging looks like: #[phase(syntax, link)] extern crate log; fn main() { debug!("Hello, world!"); }

std: Rename Chan/Port types and constructor

2014-03-13T20:23:29+00:00

* Chan => Sender * Port => Receiver * Chan::new() => channel() * constructor returns (Sender, Receiver) instead of (Receiver, Sender) * local variables named `port` renamed to `rx` * local variables named `chan` renamed to `tx` Closes #11765

native: Move from usleep() to nanosleep()

2014-03-05T17:11:10+00:00

Using nanosleep() allows us to gracefully recover from EINTR because on error it fills in the second parameter with the remaining time to sleep. Closes #12689

Publicise types/add #[allow(visible_private_types)] to a variety of places.

2014-02-28T13:12:34+00:00

There's a lot of these types in the compiler libraries, and a few of the older or private stdlib ones. Some types are obviously meant to be public, others not so much.

native: Improve windows file handling

2014-02-27T20:03:57+00:00

This commit splits the file implementation into file_unix and file_win32. The two implementations have diverged to the point that they share almost 0 code at this point, so it's easier to maintain as separate files. The other major change accompanied with this commit is that file::open is no longer based on libc's open function on windows, but rather windows's CreateFile function. This fixes dealing with binary files on windows (test added in previous commit). This also changes the read/write functions to use ReadFile and WriteFile instead of libc's read/write. Closes #12406