pub mod runtime2;

mod runtime;

mod component;

mod communication;

use std::sync::Arc;

use std::sync::atomic::AtomicU32;

use crate::protocol::*;

// -----------------------------------------------------------------------------

// Component

// -----------------------------------------------------------------------------

/// Key to a component. Type system somewhat ensures that there can only be one

/// of these. Only with a key one may retrieve privately-accessible memory for

/// a component. Practically just a generational index, like `CompId` is.

#[derive(Copy, Clone)]

pub(crate) struct CompKey(CompId);

/// Generational ID of a component

#[derive(Copy, Clone)]

pub(crate) struct CompId {

    pub index: u32,

    pub generation: u32,

}

impl PartialEq for CompId {

    fn eq(&self, other: &Self) -> bool {

        return self.index.eq(&other.index);

    }

}

impl Eq for CompId {}

/// In-runtime storage of a component

pub(crate) struct RtComp {

}

// -----------------------------------------------------------------------------

// Runtime

// -----------------------------------------------------------------------------

type RuntimeHandle = Arc<Runtime>;

/// Memory that is maintained by "the runtime". In practice it is maintained by

/// multiple schedulers, and this serves as the common interface to that memory.

pub struct Runtime {

    active_elements: AtomicU32, // active components and APIs (i.e. component creators)

}

impl Runtime {

    pub fn new(num_threads: u32, protocol_description: ProtocolDescription) -> Runtime {

        assert!(num_threads > 0, "need a thread to perform work");

        return Runtime{

            active_elements: AtomicU32::new(0),

        };

    }

}

// -----------------------------------------------------------------------------

// Runtime containers

// -----------------------------------------------------------------------------

/// Component storage. Note that it shouldn't be polymorphic, but making it so

/// allows us to test it.

// Requirements:

// 1. Performance "fastness" in order of most important:

//      1. Access (should be just index retrieval)

//      2. Creation (because we want to execute code as fast as possible)

//      3. Destruction (because create-and-run is more important than quick dying)

// 2. Somewhat safe, with most performance spent in the incorrect case

// 3. Thread-safe. Everyone and their dog will be creating and indexing into

//  the components concurrently.

// 4. Assume low contention.

//

// Some trade-offs:

// We could perhaps make component IDs just a pointer to that component. With

// an atomic counter managed by the runtime containing the number of owners

// (always starts at 1). However, this feels like too early to do something like

// that, especially because I would like to do direct messaging. Even though

// sending two u32s is the same as sending a pointer, it feels wrong for now.

//

// So instead we'll have some kind of concurrent store where we can index into.

// This means that it might have to resize. Resizing implies that everyone must

// wait until it is resized.

//

// Furthermore, it would be nice to reuse slots. That is to say: if we create a

// bunch of components and then destroy a couple of them, then the storage we

// reserved for them should be reusable.

//

// We'll go the somewhat simple route for now:

// 1. Each component will get allocated individually (and we'll define exactly

//  what we mean by this sometime later, when we start with the bytecode). This

//  way the components are pointer-stable for their lifetime.

// 2. We need to have some array that contains these pointers. We index into

//  this array with our IDs.

// 3. When we destroy components we call the destructor on the allocated memory

//  and add the index to some kind of freelist. Because only one thread can ever

//  create and/or destroy a component we have an imaginary lock on that

//  particular component's index. The freelist acts like a concurrent stack

//  where we can push/pop. If we ensure that the freelist is the same size as

//  the ID array then we can never run out of size.

// 4. At some point the array ID might be full and have to be resized. If we

//  ensure that there is only one thread which can ever fill up the array (this

//  means we *always* have one slot free, such that we can do a CAS) then we can

//  do a pointer-swap on the base pointer of all storage. This takes care of

//  resizing due to creation.

//

//  However, with a freelist accessed at the same time, we must make sure that

//  we do the copying of the old freelist and the old ID array correctly. While

//  we're creating the new array we might still be destroying components. So

//  one component calls a destructor (not too bad) and then pushes the resulting

//  ID onto the freelist stack (which is bad). We can either somehow forbid

//  destroying during resizing (which feels ridiculous) or try to be smart. Note

//  that destruction might cause later creations as well!

//

//  Since components might have to read a base pointer anyway to arrive at a

//  freelist entry or component pointer, we could set it to null and let the

//  others spinlock (or take a mutex?). So then the resizer will notice the

//

struct CompStore {

}