mirror of
https://gitlab.com/fabinfra/fabaccess/bffh.git
synced 2024-11-25 16:17:56 +01:00
Noting down improvement ideas for procs
This commit is contained in:
parent
2f5f7cb0d7
commit
ff727b6d97
@ -46,8 +46,8 @@ pub struct LightProc {
|
||||
|
||||
// LightProc is both Sync and Send because it explicitly handles synchronization internally:
|
||||
// The state of a `LightProc` is only modified atomically guaranteeing a consistent view from all
|
||||
// threads. Existing handles are atomically reference counted so the proc itself will not be dropped
|
||||
// until all pointers to it are themselves dropped.
|
||||
// threads. Existing wakers (and the proc_handle) are atomically reference counted so the proc
|
||||
// itself will not be dropped until all pointers to it are themselves dropped.
|
||||
// However, if the future or result inside the LightProc is !Send the executor must ensure that
|
||||
// the `schedule` function does not move the LightProc to a different thread.
|
||||
unsafe impl Send for LightProc {}
|
||||
|
@ -6,6 +6,7 @@ use crate::state::*;
|
||||
use std::fmt::{self, Debug, Formatter};
|
||||
use std::future::Future;
|
||||
use std::marker::{PhantomData, Unpin};
|
||||
use std::mem::MaybeUninit;
|
||||
use std::pin::Pin;
|
||||
use std::ptr::NonNull;
|
||||
use std::sync::atomic::Ordering;
|
||||
@ -24,7 +25,7 @@ pub struct ProcHandle<R> {
|
||||
/// A marker capturing the generic type `R`.
|
||||
// TODO: Instead of writing the future output to the RawProc on heap, put it in the handle
|
||||
// (if still available).
|
||||
pub(crate) result: PhantomData<R>,
|
||||
pub(crate) result: MaybeUninit<R>,
|
||||
}
|
||||
|
||||
unsafe impl<R: Send> Send for ProcHandle<R> {}
|
||||
@ -36,7 +37,7 @@ impl<R> ProcHandle<R> {
|
||||
pub(crate) fn new(raw_proc: NonNull<()>) -> Self {
|
||||
Self {
|
||||
raw_proc,
|
||||
result: PhantomData,
|
||||
result: MaybeUninit::uninit(),
|
||||
}
|
||||
}
|
||||
|
||||
@ -50,6 +51,13 @@ impl<R> ProcHandle<R> {
|
||||
let pdata = ptr as *const ProcData;
|
||||
|
||||
unsafe {
|
||||
let id = (&(*pdata).span).id().map(|id| id.into_u64()).unwrap_or(0);
|
||||
tracing::trace!(
|
||||
target: "executor::handle",
|
||||
op = "handle.cancel",
|
||||
task.id = id,
|
||||
);
|
||||
|
||||
let mut state = (*pdata).state.load(Ordering::Acquire);
|
||||
|
||||
loop {
|
||||
|
@ -20,6 +20,7 @@ use tracing::Span;
|
||||
|
||||
/// Raw pointers to the fields of a proc.
|
||||
// TODO: Make generic over the Allocator used!
|
||||
// TODO: The actual layout stored could be expressed as a struct w/ union. Maybe do that?
|
||||
pub(crate) struct RawProc<'a, F, R, S> {
|
||||
pub(crate) pdata: *const ProcData,
|
||||
pub(crate) schedule: *const S,
|
||||
@ -30,10 +31,13 @@ pub(crate) struct RawProc<'a, F, R, S> {
|
||||
|
||||
// Make the lifetime 'a of the future invariant
|
||||
_marker: PhantomData<&'a ()>,
|
||||
// TODO: We should link a proc to a process bucket for scheduling and tracing
|
||||
// => nope, do that via scheduling func
|
||||
// TODO: A proc should be able to be assigned a name for tracing and reporting
|
||||
// This could also be implemented via storing a Span similar to `Instrumented`
|
||||
// TODO: We should link a proc to a process group for scheduling and tracing
|
||||
// - sub-tasks should start in the same group by default
|
||||
// - that data needs to be available when calling `spawn` and to decide which task to run.
|
||||
// So there must be a thread-local reference to it that's managed by the executor, and
|
||||
// updated when a new task is being polled.
|
||||
// Additionally `schedule` must have a reference to it to be able to push to the right
|
||||
// queue? The `schedule` fn could just come from the group instead.
|
||||
}
|
||||
|
||||
impl<'a, F, R, S> RawProc<'a, F, R, S>
|
||||
|
Loading…
Reference in New Issue
Block a user