Lines Matching refs:fiber

23 The library's fiber manager keeps track of suspended (blocked) fibers. Only
24 when a fiber becomes ready to run is it passed to the scheduler. Of course, if
27 implementation start to influence the overall sequence of fiber execution.
30 fiber priority. We will implement it such that a fiber with higher priority is
31 preferred over a fiber with lower priority. Any fibers with equal priority
41 each fiber.[footnote A previous version of the Fiber library implicitly
42 tracked an int priority for each fiber, even though the default scheduler
44 scheduler-specific fiber properties.]
46 One might suggest deriving a custom [class_link fiber] subclass to store such
49 # __boost_fiber__ provides a number of different ways to launch a fiber.
52   associate its custom properties with ['every] fiber in the thread, not only
53   the ones explicitly launched by instantiating a custom `fiber` subclass.
57   a particular `fiber` subclass, we would have to hunt down and modify every
58   place that launches a fiber on that thread.
59 # The [class_link fiber] class is actually just a handle to internal
60   [class_link context] data. A subclass of `fiber` would not add data to
66 Instead of deriving a custom scheduler fiber properties subclass from
67 [class_link fiber], you must instead derive it from [class_link
96 The running fiber can access its own [class_link fiber_properties] subclass
103 Given a [class_link fiber] instance still connected with a running fiber (that
104 is, not [member_link fiber..detach]ed), you may access that fiber's properties
105 using [template_member_link fiber..properties]. As with
111 Launching a new fiber schedules that fiber as ready, but does ['not]
112 immediately enter its ['fiber-function]. The current fiber retains control
114 the `launch()` function above, it is reasonable to launch a fiber and
117 fiber manager calls [member_link algorithm_with_properties..pick_next].