This reimplements librustuv without using the interfaces provided by the
scheduler in libstd. This solely uses the new Runtime trait in order to
interface with the local task and perform the necessary scheduling operations.
The largest snag in this refactoring is reimplementing homing. The new runtime
trait exposes no concept of "homing" a task or forcibly sending a task to a
remote scheduler (there is no concept of a scheduler). In order to reimplement
homing, the transferrence of tasks is now done at the librustuv level instead of
the scheduler level. This means that all I/O loops now have a concurrent queue
which receives homing messages and requests.
This allows the entire implementation of librustuv to be only dependent on the
runtime trait, severing all dependence of librustuv on the scheduler and related
green-thread functions.
This is all in preparation of the introduction of libgreen and libnative.
At the same time, I also took the liberty of removing all glob imports from
librustuv.
This commit fixes the logging function to be safely implemented, as well as
forcibly requiring a task to be present to use logging macros. This is safely
implemented by transferring ownership of the logger from the task to the local
stack frame in order to perform the print. This means that if a logger does more
logging while logging a new one will be initialized and then will get
overwritten once the initial logging function returns.
Without a scheme such as this, it is possible to unsafely alias two loggers by
logging twice (unsafely borrows from the task twice).
Printing is an incredibly useful debugging utility, and it's not much help if
your debugging prints just trigger an obscure abort when you need them most. In
order to handle this case, forcibly fall back to a libc::write implementation of
printing whenever a local task is not available.
Note that this is *not* a 1:1 fallback. All 1:1 rust tasks will still have a
local Task that it can go through (and stdio will be created through the local
IO factory), this is only a fallback for "no context" rust code (such as that
setting up the context).
It is not the case that all programs will always be able to acquire an instance
of the LocalIo borrow, so this commit exposes this limitation by returning
Option<LocalIo> from LocalIo::borrow().
At the same time, a helper method LocalIo::maybe_raise() has been added in order
to encapsulate the functionality of raising on io_error if there is on local I/O
available.
For now, this moves the following modules to std::sync
* UnsafeArc (also removed unwrap method)
* mpsc_queue
* spsc_queue
* atomics
* mpmc_bounded_queue
* deque
We may want to remove some of the queues, but for now this moves things out of
std::rt into std::sync
This module contains many M:N specific concepts. This will no longer be
available with libgreen, and most functions aren't really that necessary today
anyway. New testing primitives will be introduced as they become available for
1:1 and M:N.
A new io::test module is introduced with the new ip4/ip6 address helpers to
continue usage in io tests.
This trait is used to abstract the differences between 1:1 and M:N scheduling
and is the sole dispatch point for the differences between these two scheduling
modes.
This, and the following series of commits, is not intended to compile. Only
after the entire transition is complete are programs expected to compile.
So that `Uuid` can be used as the key in a `HashMap` or in a `HashSet`, etc
The only question I have about this is: Is endianness an issue, here? If so, what's the correct way to proceed?
Could prevent callers from catching the situation and lead to e.g early
iterator terminations (cf. `Reader::read_byte`) since `None` is only to
be returned only on EOF.
This adds support for the `--test` flag to rustdoc which will parse a crate,
extract all code examples in doc comments, and then run each test in the
extra::test driver.
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?
Closes#11067
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?
Closes#11067
Using --dep-info writes Makefile-compatible dependency info to a file that is by default named based on the crate source filename. This adds an optional string argument to the --dep-info option which allows to write dependency info to an arbitrary filename.
cc #10698
This uses quite a bit of unsafe code for speed and failure safety, and allocates `2*n` temporary storage.
[Performance](https://gist.github.com/huonw/5547f2478380288a28c2):
| n | new | priority_queue | quick3 |
|-------:|---------:|---------------:|---------:|
| 5 | 200 | 155 | 106 |
| 100 | 6490 | 8750 | 5810 |
| 10000 | 1300000 | 1790000 | 1060000 |
| 100000 | 16700000 | 23600000 | 12700000 |
| sorted | 520000 | 1380000 | 53900000 |
| trend | 1310000 | 1690000 | 1100000 |
(The times are in nanoseconds, having subtracted the set-up time (i.e. the `just_generate` bench target).)
I imagine that there is still significant room for improvement, particularly because both priority_queue and quick3 are doing a static call via `Ord` or `TotalOrd` for the comparisons, while this is using a (boxed) closure.
Also, this code does not `clone`, unlike `quick_sort3`; and is stable, unlike both of the others.
Trap the io_error condition so that a more informative error message is
displayed when the linker program cannot be started, such as when the
name of the linker binary is accidentally mistyped.
closes#10755
Upon inspecting the core dumps, they're all segfaulting at the same instruction
with the same value in a register that looks fishy. It appears to be indexing
into an array with a -1 index and then getting some weird overflow and dying.
I have attempted to fix this as part of
alexcrichton/libuv@fd5308383c,
but I am unsure of whether this is the actual cause of the problem, so I am not
going to upstream it just yet. I have a fairly high confidence that this is
indeed the problem, but I want to make sure that the bots to segfault all over
the place before upstreaming.
3 minor clean-ups now that #9629 is fixed:
* Update MutChunkIter to remove the ```remainder``` that existed just to allow the size_hint() method to be implemented. This is no longer necessary since we can just access the length of the slice directly.
* Update MutSplitIterator to address the FIXME in its size_hint() method. This method was only partially implemented due to the issue. Also, implement a minor optimization in the case that its the last iteration.
* Update ByRef iterator to implement the size_hint() method.
I noticed that MutSplitIterator returns an empty slice if called on an empty slice. I don't know if this is intended or not, but I left the ```finished``` field in-place to preserve this behavior.
@TeXitoi @blake2-ppc
Update the next() method to just return self.v in the case that we've reached
the last element that the iterator will yield. This produces equivalent
behavior as before, but without the cost of updating the field.
Update the size_hint() method to return a better hint now that #9629 is fixed.
Right now the --crate-id and related flags are all process *after* the entire
crate is parsed. This is less than desirable when used with makefiles because it
means that just to learn the output name of the crate you have to parse the
entire crate (unnecessary).
This commit changes the behavior to lift the handling of these flags much sooner
in the compilation process. This allows us to not have to parse the entire crate
and only have to worry about parsing the crate attributes themselves. The
related methods have all been updated to take an array of attributes rather than
a crate.
Additionally, this ceases duplication of the "what output are we producing"
logic in order to correctly handle things in the case of --test.
Finally, this adds tests for all of this functionality to ensure that it does
not regress.
Alex Crichton