Implements various missing tcp & udp methods.. Also fixes handling ipv4-mapped/compatible ipv6 addresses and addresses the XXX on `status_to_maybe_uv_error`.
r? @brson
cc #6004 and #3273
This is a rewrite of TLS to get towards not requiring `@` when using task local storage. Most of the rewrite is straightforward, although there are two caveats:
1. Changing `local_set` to not require `@` is blocked on #7673
2. The code in `local_pop` is some of the most unsafe code I've written. A second set of eyes should definitely scrutinize it...
The public-facing interface currently hasn't changed, although it will have to change because `local_data::get` cannot return `Option<T>`, nor can it return `Option<&T>` (the lifetime isn't known). This will have to be changed to be given a closure which yield `&T` (or as an Option). I didn't do this part of the api rewrite in this pull request as I figured that it could wait until when `@` is fully removed.
This also doesn't deal with the issue of using something other than functions as keys, but I'm looking into using static slices (as mentioned in the issues).
r? @graydon, @nikomatsakis, @pcwalton, or @catamorphism
Sorry this is so huge, but it's been accumulating for about a month. There's lots of stuff here, mostly oriented toward enabling multithreaded scheduling and improving compatibility between the old and new runtimes. Adds task pinning so that we can create the 'platform thread' in servo.
[Here](e1555f9b56/src/libstd/rt/mod.rs (L201)) is the current runtime setup code.
About half of this has already been reviewed.
* stop using an atomic counter, this has a significant cost and
valgrind will already catch these leaks
* remove the extra layer of function calls
* remove the assert of non-null in free, freeing null is well defined
but throwing a failure from free will not be
* stop initializing the `prev`/`next` pointers
* abort on out-of-memory, failing won't necessarily work
This avoids the following pathological scenario that makes threadring OOM:
1) task calls C using fast_ffi, borrowing a big stack from the scheduler.
2) task returns from C and places the big stack on the task-local stack segment list
3) task calls further Rust functions that require growing the stack, and for this reuses the big stack
4) task yields, failing to return the big stack to the scheduler.
5) repeat 500+ times and OOM
Conflicts:
src/rt/rust_task.cpp
This sets the `get_tydesc()` return type correctly and removes the intrinsic module. See #3730, #3475.
Update: this now also removes the unused shape fields in tydescs.
Under valgrind on 64->32 cross compiles the dynamic linker is emitting
some error messages on stderr, which interferes with the tests that
are checking stderr.
This commit fixes#7022 - I've added an additional check to ensure that
stk is not null before dereferencing it to get it's next element,
assigning NULL if it is itself NULL.
This commit fixes#7022 - I've added an additional check to ensure that
stk is not null before dereferencing it to get it's next element,
assigning NULL if it is itself NULL.
r? @jld or @graydon
The calculation looks right to me, but perhaps one of you two can double check. You two seem like you are doing the most recent work in this sort of area.
Fix for #6575. In the trans phase, rustc emits code for a function parameter that goes completely unused in the event the return type of the function in question happens to be an immediate.
This patch modifies rustc & parts of rustrt to ensure that the vestigial parameter is no longer present in compiled code.
r?
This is all of my scheduler work on #4419 from the last 3 weeks or so. I've had a few failed pull requests so far but I think the problems are ironed out.
* TCP
* The beginnings of runtime embedding APIs
* Porting various corners of core to be compatible with both schedulers
* libuv timer bindings
* Further refinement of I/O error handling, including a new, incomplete, `read_error` condition
* Incomplete refactoring to make tasks work without coroutines and user-space scheduling
* Implementations of Reader/Writer extension methods
* Implementations of the most important part of core::comm
I'm particularly happy with how easy the [comm types on top of the scheduler](https://github.com/brson/rust/blob/io-upstream/src/libcore/rt/comm.rs). Note that these implementations do not use pipes. If anything here needs careful review though it's this code.
This branch passes 95% of the run-pass tests (with `TESTARGS=--newrt`)
In the next week I'll probably spend some time adding preliminary multithreading and seeing how close we are to removing the old runtime.
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
I changed ```RED_ZONE_SIZE``` to ```RZ_MAC_32``` because of stack canary failure.
Here is a LLVM patch for MIPS segmented stacks.
http://people.cs.nctu.edu.tw/~jyyou/rust/mips-segstk.patch
Current test results
```
failures:
rand::tests::test_rng_seeded_custom_seed2
run::tests::test_forced_destroy_actually_kills
run::tests::test_unforced_destroy_actually_kills
time::tests::run_tests
uv_ll::test::test_uv_ll_struct_size_addrinfo
uv_ll::test::test_uv_ll_struct_size_uv_timer_t
segfaults:
rt::io::option::test::test_option_writer_error
rt::local_services::test::unwind
rt::sched::test_swap_tasks_then
stackwalk::test_simple
stackwalk::test_simple_deep
```
Hi there,
Really enjoying Rust. Noticed a few typos so I searched around for a few more--here's some fixes.
Ran `make check` and got `summary of 24 test runs: 4868 passed; 0 failed; 330 ignored`.
Thanks!
Sean
transitional patch to resolve compile/link failure on android
after #6161 landed, I've encountered below errors since android does not support glob in libc.
/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'glob'
/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'globfre
Since android does not have `glob.h`, `glob_t` definition comes from
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/vSH6MWPD0Vk#6100 should be resolved.
This means that `ub4`s are always 4 bytes, rather than being 8 bytes on
x64. (Suggested but not implemented by upstream: "Porting it to a 64-bit
machine [...] may just need an adjustment of the definition of ub4")
The "unsigned 4 byte" `ub4`s are actually 8 bytes on 64-bit platforms
which mean that some bits > 2**32 were retained in calculations, these
would then "reappear" after a shift and so the stream of random numbers
would differ on 32 bit vs 64 bit platforms.
This also reverts some changes to TLS that were leaking memory.
Conflicts:
src/libcore/rt/uv/net.rs
src/libcore/task/local_data_priv.rs
src/libcore/unstable/lang.rs
Like I commented in #2043, I can't reproduce the weirdness from #1388 on either mac or linux (x84_64) and pushing to try gives all green.
That's 128 less bytes to have to keep in the stack for every call to __morestack.
This Adds a bunch of tests for passing and returning structs
of various sizes to C. It fixes the struct return rules on unix,
and on windows for structs of size > 8 bytes. Struct passing
on unix for structs under a certain size appears to still be broken.
r?
There are a lot of commits here, but not all that much substance. Mostly just refactoring.
I started sketching out the beginnings of a very simple I/O API in `core::rt::io` that represents I/O streams as a single `Stream` trait instead of `Reader` / `Writer` pairs. This seems to be the more common pattern (at least this is how the .NET BCL does it) and it seems to me that separate readers and writers would make duplex streams very awkward. Regardless, I don't intend to go very far down the I/O API design road without some mailing list discussion.
I've also started on the uv bindings for file I/O but haven't gotten very far.
Also hooked up the new scheduler to `rust_start` and the compiletest driver. 70% of run-pass test cases already pass, but I wouldn't read too much into that.
I also split the direct, low-level uv bindings in two so that the scheduler can have its own set, leaving `std::net` on its own.
As per #2521. Inlining seems to improve performance slightly:
Inlined Not Inlined
x86: 13.5482 14.4112
x86_64: 17.4712 18.0696
(Average of 5 runs timed with `time`)
```Rust
fn foo() -> int {
int::from_str(~"28098").unwrap()
}
fn main() {
for 1000000.times {
foo();
foo();
foo();
foo();
foo();
}
}
```
All run on:
Linux 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux
The MIPS and ARM bits I didn't inline since I'm not as familiar with them and I also can't test them. All green on try.
adjusting a few foreign functions that were declared with by-ref
mode. This also allows us to remove by-val mode in the near future.
With copy mode, though, we have to be careful because Rust will implicitly pass
somethings by pointer but this may not be the C ABI rules. For example, rust
will pass a struct Foo as a Foo*. So I added some code into the adapters to
fix this (though the C ABI rules may put the pointer back, oh well).
This patch also includes a lint mode for the use of by-ref mode
in foreign functions as the semantics of this have changed.
The correct opendir/readdir to use appear to be the 64-bit versions called
opendir$INODE64, etc. but for some reason I can't get them to link properly
on i686. Putting them in librustrt and making gcc figure it out works.
This mystery will have to wait for another day.
