Skip to content

Commit 41c6b36

Browse files
committed
---
yaml --- r: 148974 b: refs/heads/try2 c: 940d1ae h: refs/heads/master v: v3
1 parent 71be94b commit 41c6b36

File tree

20 files changed

+192
-365
lines changed

20 files changed

+192
-365
lines changed

[refs]

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
55
refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
66
refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
77
refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
8-
refs/heads/try2: 29e500db8a98a86b3de56688cd9fa6571a840470
8+
refs/heads/try2: 940d1ae2f3b1cba8cfd858ab3a54d6408b53b033
99
refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
1010
refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
1111
refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -75,6 +75,7 @@ src/.DS_Store
7575
/nd/
7676
/llvm/
7777
version.md
78+
*.tex
7879
keywords.md
7980
x86_64-apple-darwin/
8081
x86_64-unknown-linux-gnu/

branches/try2/mk/docs.mk

Lines changed: 6 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -19,10 +19,8 @@ HTML_DEPS := doc/
1919

2020
BASE_DOC_OPTS := --standalone --toc --number-sections
2121
HTML_OPTS = $(BASE_DOC_OPTS) --to=html5 --section-divs --css=rust.css \
22-
--include-before-body=doc/version_info.html \
23-
--include-in-header=doc/favicon.inc --include-after-body=doc/footer.inc
24-
TEX_OPTS = $(BASE_DOC_OPTS) --include-before-body=doc/version.md \
25-
--from=markdown --include-before-body=doc/footer.tex --to=latex
22+
--include-before-body=doc/version_info.html --include-in-header=doc/favicon.inc
23+
TEX_OPTS = $(BASE_DOC_OPTS) --include-before-body=doc/version.md --to=latex
2624
EPUB_OPTS = $(BASE_DOC_OPTS) --to=epub
2725

2826
D := $(S)src/doc
@@ -57,21 +55,12 @@ doc/rust.css: $(D)/rust.css | doc/
5755
@$(call E, cp: $@)
5856
$(Q)cp -a $< $@ 2> /dev/null
5957

60-
HTML_DEPS += doc/favicon.inc
61-
doc/favicon.inc: $(D)/favicon.inc | doc/
62-
@$(call E, cp: $@)
63-
$(Q)cp -a $< $@ 2> /dev/null
64-
6558
doc/full-toc.inc: $(D)/full-toc.inc | doc/
6659
@$(call E, cp: $@)
6760
$(Q)cp -a $< $@ 2> /dev/null
6861

69-
HTML_DEPS += doc/footer.inc
70-
doc/footer.inc: $(D)/footer.inc | doc/
71-
@$(call E, cp: $@)
72-
$(Q)cp -a $< $@ 2> /dev/null
73-
74-
doc/footer.tex: $(D)/footer.tex | doc/
62+
HTML_DEPS += doc/favicon.inc
63+
doc/favicon.inc: $(D)/favicon.inc | doc/
7564
@$(call E, cp: $@)
7665
$(Q)cp -a $< $@ 2> /dev/null
7766

@@ -94,7 +83,7 @@ doc/rust.html: $(D)/rust.md doc/full-toc.inc $(HTML_DEPS) | doc/
9483
$(CFG_PANDOC) $(HTML_OPTS) --include-in-header=doc/full-toc.inc --output=$@
9584

9685
DOCS += doc/rust.tex
97-
doc/rust.tex: $(D)/rust.md doc/footer.tex doc/version.md | doc/
86+
doc/rust.tex: $(D)/rust.md doc/version.md | doc/
9887
@$(call E, pandoc: $@)
9988
$(Q)$(CFG_NODE) $(D)/prep.js $< | \
10089
$(CFG_PANDOC) $(TEX_OPTS) --output=$@
@@ -118,7 +107,7 @@ doc/tutorial.html: $(D)/tutorial.md $(HTML_DEPS)
118107
$(CFG_PANDOC) $(HTML_OPTS) --output=$@
119108

120109
DOCS += doc/tutorial.tex
121-
doc/tutorial.tex: $(D)/tutorial.md doc/footer.tex doc/version.md
110+
doc/tutorial.tex: $(D)/tutorial.md doc/version.md
122111
@$(call E, pandoc: $@)
123112
$(Q)$(CFG_NODE) $(D)/prep.js $< | \
124113
$(CFG_PANDOC) $(TEX_OPTS) --output=$@

branches/try2/src/doc/footer.inc

Lines changed: 0 additions & 7 deletions
This file was deleted.

branches/try2/src/doc/footer.tex

Lines changed: 0 additions & 7 deletions
This file was deleted.

branches/try2/src/doc/guide-runtime.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -236,7 +236,9 @@ extern mod green;
236236
237237
#[start]
238238
fn start(argc: int, argv: **u8) -> int {
239-
green::start(argc, argv, main)
239+
green::start(argc, argv, proc() {
240+
main();
241+
})
240242
}
241243
242244
fn main() {}

branches/try2/src/doc/rust.css

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,7 @@
1515
body {
1616
margin: 0 auto;
1717
padding: 0 15px;
18+
margin-bottom: 4em;
1819
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
1920
font-size: 14px;
2021
color: #333;
@@ -75,15 +76,6 @@ p {
7576
margin: 0 0 10px;
7677
}
7778

78-
footer {
79-
border-top: 1px solid #ddd;
80-
font-size: 12px;
81-
font-style: italic;
82-
padding-top: 4px;
83-
margin-top: 4em;
84-
margin-bottom: 1em;
85-
}
86-
8779
/* Links layout
8880
========================================================================== */
8981
a {

branches/try2/src/libgreen/lib.rs

Lines changed: 3 additions & 149 deletions
Original file line numberDiff line numberDiff line change
@@ -12,156 +12,10 @@
1212
//!
1313
//! This library provides M:N threading for rust programs. Internally this has
1414
//! the implementation of a green scheduler along with context switching and a
15-
//! stack-allocation strategy. This can be optionally linked in to rust
16-
//! programs in order to provide M:N functionality inside of 1:1 programs.
15+
//! stack-allocation strategy.
1716
//!
18-
//! # Architecture
19-
//!
20-
//! An M:N scheduling library implies that there are N OS thread upon which M
21-
//! "green threads" are multiplexed. In other words, a set of green threads are
22-
//! all run inside a pool of OS threads.
23-
//!
24-
//! With this design, you can achieve _concurrency_ by spawning many green
25-
//! threads, and you can achieve _parallelism_ by running the green threads
26-
//! simultaneously on multiple OS threads. Each OS thread is a candidate for
27-
//! being scheduled on a different core (the source of parallelism), and then
28-
//! all of the green threads cooperatively schedule amongst one another (the
29-
//! source of concurrency).
30-
//!
31-
//! ## Schedulers
32-
//!
33-
//! In order to coordinate among green threads, each OS thread is primarily
34-
//! running something which we call a Scheduler. Whenever a reference to a
35-
//! Scheduler is made, it is synonymous to referencing one OS thread. Each
36-
//! scheduler is bound to one and exactly one OS thread, and the thread that it
37-
//! is bound to never changes.
38-
//!
39-
//! Each scheduler is connected to a pool of other schedulers (a `SchedPool`)
40-
//! which is the thread pool term from above. A pool of schedulers all share the
41-
//! work that they create. Furthermore, whenever a green thread is created (also
42-
//! synonymously referred to as a green task), it is associated with a
43-
//! `SchedPool` forevermore. A green thread cannot leave its scheduler pool.
44-
//!
45-
//! Schedulers can have at most one green thread running on them at a time. When
46-
//! a scheduler is asleep on its event loop, there are no green tasks running on
47-
//! the OS thread or the scheduler. The term "context switch" is used for when
48-
//! the running green thread is swapped out, but this simply changes the one
49-
//! green thread which is running on the scheduler.
50-
//!
51-
//! ## Green Threads
52-
//!
53-
//! A green thread can largely be summarized by a stack and a register context.
54-
//! Whenever a green thread is spawned, it allocates a stack, and then prepares
55-
//! a register context for execution. The green task may be executed across
56-
//! multiple OS threads, but it will always use the same stack and it will carry
57-
//! its register context across OS threads.
58-
//!
59-
//! Each green thread is cooperatively scheduled with other green threads.
60-
//! Primarily, this means that there is no pre-emption of a green thread. The
61-
//! major consequence of this design is that a green thread stuck in an infinite
62-
//! loop will prevent all other green threads from running on that particular
63-
//! scheduler.
64-
//!
65-
//! Scheduling events for green threads occur on communication and I/O
66-
//! boundaries. For example, if a green task blocks waiting for a message on a
67-
//! channel some other green thread can now run on the scheduler. This also has
68-
//! the consequence that until a green thread performs any form of scheduling
69-
//! event, it will be running on the same OS thread (unconditionally).
70-
//!
71-
//! ## Work Stealing
72-
//!
73-
//! With a pool of schedulers, a new green task has a number of options when
74-
//! deciding where to run initially. The current implementation uses a concept
75-
//! called work stealing in order to spread out work among schedulers.
76-
//!
77-
//! In a work-stealing model, each scheduler maintains a local queue of tasks to
78-
//! run, and this queue is stolen from by other schedulers. Implementation-wise,
79-
//! work stealing has some hairy parts, but from a user-perspective, work
80-
//! stealing simply implies what with M green threads and N schedulers where
81-
//! M > N it is very likely that all schedulers will be busy executing work.
82-
//!
83-
//! # Considerations when using libgreen
84-
//!
85-
//! An M:N runtime has both pros and cons, and there is no one answer as to
86-
//! whether M:N or 1:1 is appropriate to use. As always, there are many
87-
//! advantages and disadvantages between the two. Regardless of the workload,
88-
//! however, there are some aspects of using green thread which you should be
89-
//! aware of:
90-
//!
91-
//! * The largest concern when using libgreen is interoperating with native
92-
//! code. Care should be taken when calling native code that will block the OS
93-
//! thread as it will prevent further green tasks from being scheduled on the
94-
//! OS thread.
95-
//!
96-
//! * Native code using thread-local-storage should be approached
97-
//! with care. Green threads may migrate among OS threads at any time, so
98-
//! native libraries using thread-local state may not always work.
99-
//!
100-
//! * Native synchronization primitives (e.g. pthread mutexes) will also not
101-
//! work for green threads. The reason for this is because native primitives
102-
//! often operate on a _os thread_ granularity whereas green threads are
103-
//! operating on a more granular unit of work.
104-
//!
105-
//! * A green threading runtime is not fork-safe. If the process forks(), it
106-
//! cannot expect to make reasonable progress by continuing to use green
107-
//! threads.
108-
//!
109-
//! Note that these concerns do not mean that operating with native code is a
110-
//! lost cause. These are simply just concerns which should be considered when
111-
//! invoking native code.
112-
//!
113-
//! # Starting with libgreen
114-
//!
115-
//! ```rust
116-
//! extern mod green;
117-
//!
118-
//! #[start]
119-
//! fn start(argc: int, argv: **u8) -> int { green::start(argc, argv, main) }
120-
//!
121-
//! fn main() {
122-
//! // this code is running in a pool of schedulers
123-
//! }
124-
//! ```
125-
//!
126-
//! # Using a scheduler pool
127-
//!
128-
//! ```rust
129-
//! use std::task::TaskOpts;
130-
//! use green::{SchedPool, PoolConfig};
131-
//! use green::sched::{PinnedTask, TaskFromFriend};
132-
//!
133-
//! let config = PoolConfig::new();
134-
//! let mut pool = SchedPool::new(config);
135-
//!
136-
//! // Spawn tasks into the pool of schedulers
137-
//! pool.spawn(TaskOpts::new(), proc() {
138-
//! // this code is running inside the pool of schedulers
139-
//!
140-
//! spawn(proc() {
141-
//! // this code is also running inside the same scheduler pool
142-
//! });
143-
//! });
144-
//!
145-
//! // Dynamically add a new scheduler to the scheduler pool. This adds another
146-
//! // OS thread that green threads can be multiplexed on to.
147-
//! let mut handle = pool.spawn_sched();
148-
//!
149-
//! // Pin a task to the spawned scheduler
150-
//! let task = pool.task(TaskOpts::new(), proc() { /* ... */ });
151-
//! handle.send(PinnedTask(task));
152-
//!
153-
//! // Schedule a task on this new scheduler
154-
//! let task = pool.task(TaskOpts::new(), proc() { /* ... */ });
155-
//! handle.send(TaskFromFriend(task));
156-
//!
157-
//! // Handles keep schedulers alive, so be sure to drop all handles before
158-
//! // destroying the sched pool
159-
//! drop(handle);
160-
//!
161-
//! // Required to shut down this scheduler pool.
162-
//! // The task will fail if `shutdown` is not called.
163-
//! pool.shutdown();
164-
//! ```
17+
//! This can be optionally linked in to rust programs in order to provide M:N
18+
//! functionality inside of 1:1 programs.
16519
16620
#[crate_id = "green#0.10-pre"];
16721
#[license = "MIT/ASL2"];

branches/try2/src/libnative/lib.rs

Lines changed: 1 addition & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -8,38 +8,11 @@
88
// option. This file may not be copied, modified, or distributed
99
// except according to those terms.
1010

11-
//! The native I/O and threading crate
11+
//! The native runtime crate
1212
//!
1313
//! This crate contains an implementation of 1:1 scheduling for a "native"
1414
//! runtime. In addition, all I/O provided by this crate is the thread blocking
1515
//! version of I/O.
16-
//!
17-
//! # Starting with libnative
18-
//!
19-
//! ```rust
20-
//! extern mod native;
21-
//!
22-
//! #[start]
23-
//! fn start(argc: int, argv: **u8) -> int { native::start(argc, argv, main) }
24-
//!
25-
//! fn main() {
26-
//! // this code is running on the main OS thread
27-
//! }
28-
//! ```
29-
//!
30-
//! # Force spawning a native task
31-
//!
32-
//! ```rust
33-
//! extern mod native;
34-
//!
35-
//! fn main() {
36-
//! // We're not sure whether this main function is run in 1:1 or M:N mode.
37-
//!
38-
//! native::task::spawn(proc() {
39-
//! // this code is guaranteed to be run on a native thread
40-
//! });
41-
//! }
42-
//! ```
4316
4417
#[crate_id = "native#0.10-pre"];
4518
#[license = "MIT/ASL2"];

branches/try2/src/librustc/middle/trans/base.rs

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -352,7 +352,6 @@ pub fn malloc_raw_dyn<'a>(
352352
if heap == heap_exchange {
353353
let llty_value = type_of::type_of(ccx, t);
354354

355-
356355
// Allocate space:
357356
let r = callee::trans_lang_call(
358357
bcx,
@@ -375,17 +374,18 @@ pub fn malloc_raw_dyn<'a>(
375374
// Grab the TypeRef type of box_ptr_ty.
376375
let box_ptr_ty = ty::mk_box(bcx.tcx(), t);
377376
let llty = type_of(ccx, box_ptr_ty);
377+
let llalign = C_uint(ccx, llalign_of_min(ccx, llty) as uint);
378378

379379
// Get the tydesc for the body:
380380
let static_ti = get_tydesc(ccx, t);
381381
glue::lazily_emit_tydesc_glue(ccx, abi::tydesc_field_drop_glue, static_ti);
382382

383383
// Allocate space:
384-
let tydesc = PointerCast(bcx, static_ti.tydesc, Type::i8p());
384+
let drop_glue = static_ti.drop_glue.get().unwrap();
385385
let r = callee::trans_lang_call(
386386
bcx,
387387
langcall,
388-
[tydesc, size],
388+
[PointerCast(bcx, drop_glue, Type::glue_fn(Type::i8p()).ptr_to()), size, llalign],
389389
None);
390390
rslt(r.bcx, PointerCast(r.bcx, r.val, llty))
391391
}

branches/try2/src/librustc/middle/trans/debuginfo.rs

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1779,7 +1779,7 @@ fn boxed_type_metadata(cx: &CrateContext,
17791779
offset: ComputedMemberOffset,
17801780
},
17811781
MemberDescription {
1782-
name: ~"tydesc",
1782+
name: ~"drop_glue",
17831783
llvm_type: member_llvm_types[1],
17841784
type_metadata: nil_pointer_type_metadata,
17851785
offset: ComputedMemberOffset,
@@ -1824,7 +1824,7 @@ fn boxed_type_metadata(cx: &CrateContext,
18241824
-> bool {
18251825
member_llvm_types.len() == 5 &&
18261826
member_llvm_types[0] == cx.int_type &&
1827-
member_llvm_types[1] == cx.tydesc_type.ptr_to() &&
1827+
member_llvm_types[1] == Type::generic_glue_fn(cx).ptr_to() &&
18281828
member_llvm_types[2] == Type::i8().ptr_to() &&
18291829
member_llvm_types[3] == Type::i8().ptr_to() &&
18301830
member_llvm_types[4] == content_llvm_type

0 commit comments

Comments
 (0)