Function futures::task::init [−][src]
pub unsafe fn init(get: fn() -> *mut u8, set: fn(_: *mut u8)) -> bool
Expand description
Initialize the futures
task system.
This function is an unsafe low-level implementation detail typically only
used by crates using futures
in no_std
context. Users of this crate
who also use the standard library never need to invoke this function.
The task system in the futures
crate relies on some notion of “local
storage” for the running thread and/or context. The task::current
function
can get invoked in any context, for example, and needs to be able to return
a Task
. Typically with the standard library this is supported with
thread-local-storage, but this is not available in no_std
contexts!
This function is provided to allow no_std
contexts to continue to be able
to use the standard task system in this crate. The functions provided here
will be used as-if they were thread-local-storage getters/setters. The get
function provided is used to retrieve the current thread-local value of the
task system’s pointer, returning null if not initialized. The set
function
updates the value of the pointer.
Return value
This function will return whether initialization succeeded or not. This
function can be called concurrently and only the first invocation will
succeed. If false
is returned then the get
and set
pointers provided
were not registered for use with the task system, but if true
was
provided then they will be called when the task system is used.
Note that while safe to call concurrently it’s recommended to still perform
external synchronization when calling this function. This task system is
not guaranteed to be ready to go until a call to this function returns
true
. In other words, if you call this function and see false
, the
task system may not be ready to go as another thread may still be calling
init
.
Unsafety
This function is unsafe due to the requirements on the behavior of the
get
and set
functions. The pointers returned from these functions must
reflect the semantics specified above and must also be thread-local,
depending on the definition of a “thread” in the calling context.