publish maitake

[jamesmunns]

Currently, the publishing of the maitake crate is gated on two things:

• Publishing mycelium-bitfield - publish mycelium-bitfield #246
• Publishing (or duplicating portions of) mycelium-util

Regarding the second point, here's all the usage sites of mycelium_util in maitake at the moment:

Searching 25 files for "mycelium_util"

/home/james/personal/mycelium/maitake/src/loom.rs:
   50          pub use core::sync::*;
   51  
   52:         pub use mycelium_util::sync::spin;
   53      }
   54  

/home/james/personal/mycelium/maitake/src/task.rs:
   37  
   38  use cordyceps::{mpsc_queue, Linked};
   39: use mycelium_util::fmt;
   40  
   41  /// A type-erased, reference-counted pointer to a spawned [`Task`].

/home/james/personal/mycelium/maitake/src/scheduler/tests.rs:
   43  mod alloc {
   44      use super::*;
   45:     use mycelium_util::sync::Lazy;
   46  
   47      #[test]

/home/james/personal/mycelium/maitake/src/sync/mutex.rs:
   12      task::{Context, Poll},
   13  };
   14: use mycelium_util::{fmt, unreachable_unchecked};
   15  use pin_project::pin_project;
   16  
   ..
   27  /// shared data is available. This is in contrast to *blocking* mutices, such as
   28  /// [`std::sync::Mutex`], which wait by blocking the current thread[^1], or
   29: /// *spinlock* based mutices, such as [`mycelium_util::sync::spin::Mutex`],
   30  /// which wait by spinning in a busy loop.
   31  ///
   ..
   46  /// has had a chance to lock the shared data. Again, this is in contrast to
   47  /// [`std::sync::Mutex`], where fairness depends on the underlying OS' locking
   48: /// primitives; and [`mycelium_util::sync::spin::Mutex`] and
   49  /// [`futures_util::lock::Mutex`], which will never guarantee fairness.
   50  ///
   ..
   71  /// [fairly queued]: https://en.wikipedia.org/wiki/Unbounded_nondeterminism#Fairness
   72  /// [`std::sync::Mutex`]: https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html
   73: /// [`mycelium_util::sync::spin::Mutex`]: https://mycelium.elizas.website/mycelium_util/sync/spin/struct.mutex
   74  /// [`futures-util`]: https://crates.io/crate/futures-util
   75  /// [`futures_util::lock::Mutex`]: https://docs.rs/futures-util/latest/futures_util/lock/struct.Mutex.html

/home/james/personal/mycelium/maitake/src/task/task_list.rs:
    1  use super::Task;
    2: use mycelium_util::{intrusive::list, sync::spin};
    3  pub(crate) struct TaskList {
    4      inner: spin::Mutex<Inner>,

/home/james/personal/mycelium/maitake/src/wait/cell.rs:
   12      task::{Context, Poll, Waker},
   13  };
   14: use mycelium_util::{fmt, sync::CachePadded};
   15  
   16  /// An error indicating that a [`WaitCell`] was closed or busy while

/home/james/personal/mycelium/maitake/src/wait/map.rs:
   23  };
   24  use mycelium_bitfield::FromBits;
   25: use mycelium_util::fmt;
   26: use mycelium_util::sync::CachePadded;
   27  use pin_project::{pin_project, pinned_drop};
   28  
   ..
  187      /// node.
  188      ///
  189:     /// A spinlock (from `mycelium_util`) is used here, in order to support
  190      /// `no_std` platforms; when running `loom` tests, a `loom` mutex is used
  191      /// instead to simulate the spinlock, because loom doesn't play nice with
  ...
  879              _ => unsafe {
  880                  // TODO(AJM): this isn't *totally* true anymore...
  881:                 mycelium_util::unreachable_unchecked!(
  882                      "all potential 2-bit patterns should be covered!"
  883                  )

/home/james/personal/mycelium/maitake/src/wait/queue.rs:
   24  use mycelium_bitfield::{bitfield, FromBits};
   25  #[cfg(test)]
   26: use mycelium_util::fmt;
   27: use mycelium_util::sync::CachePadded;
   28  use pin_project::{pin_project, pinned_drop};
   29  
   ..
  185      /// node.
  186      ///
  187:     /// A spinlock (from `mycelium_util`) is used here, in order to support
  188      /// `no_std` platforms; when running `loom` tests, a `loom` mutex is used
  189      /// instead to simulate the spinlock, because loom doesn't play nice with
  ...
  851              bits if bits == Self::Closed as u8 => Self::Closed,
  852              _ => unsafe {
  853:                 mycelium_util::unreachable_unchecked!(
  854                      "all potential 2-bit patterns should be covered!"
  855                  )

[hawkw]

I'm happy to publish mycelium-util, AFAICT there are no real blockers.

I think the main issue is actually going to be handling the tracing 0.2 git dep. I don't think the crate can ever be published while it has a git dependency, which is unfortunate. If we want to publish maitake before tracing 0.2 is released, we may have to remove support for it entirely.

Is it important that maitake be on crates.io?

[jamesmunns]

Is it important that maitake be on crates.io?

Not at all yet! Eventually when mnemos gets closer to the 0.2 release (end of summer-ish? Aug/Sept? Maybe?) it would be good.

When it gets closer, we can see how things are going with tracing, and what makes sense to do then,

[philpax]

Hi there! I was wondering if there are still plans to publish maitake.

I'd like to use it to replace the ad-hoc executor I built for the WASM Rust guest runtime for Ambient (which is not very sound or efficient). However, the Ambient API is published to crates.io, which means I can't publish a version using maitake.

I'm in no particular rush to do this, but I'd rather use maitake and its much more robust machinery over my poll-every-tick executor :-)

[hawkw]

@philpax I'm definitely open to publishing maitake if you're interested in using it! The primary reason it hasn't yet been published is that there hasn't been a ton of demand for consuming it as a crates.io dependency, so if it's something you'd like to see, I'm very willing to prioritize it!

We would need to remove the tracing 0.2 diagnostics, since tracing 0.2 is not yet released. However, I'm open to considering this --- in practice, most of the tracing in maitake is useful primarily for (a) internal debugging, such as in tests, for which tracing 0.1 is fine, and (b) tokio-console support, which requires tracing 0.1 anyway. I'd also like to do a docs and API pass.

A published release of maitake would be a v0.1.0 release, and I would probably reserve the right to release new breaking change versions frequently, as the API is still evolving.

[philpax]

Fantastic, thank you! I'll try wiring up a Git version of maitake to validate that it'll all work as expected this week. If all goes well, I'll let you know and we can go from there 🙂

Regarding the tracing issue - would it be possible to use log by default, and add tracing as an optional dependency? It's no biggie either way - adding another dependency won't hurt us, and we'll need to set up some kind of logging framework some day anyway - but it might be worth considering for other users.

Breaking changes are totally fine. I don't think we'll be doing anything too complicated to begin with given the constraints of the WASM single-threaded environment of the guest.

Thanks once again 🙏

[hawkw]

Regarding the tracing issue - would it be possible to use log by default, and add tracing as an optional dependency? It's no biggie either way - adding another dependency won't hurt us, and we'll need to set up some kind of logging framework some day anyway - but it might be worth considering for other users.

You'll be able to use tracing 0.1, and can emit log logs using tracing 0.1's log compatibility feature. It's specifically the support for the unreleased v0.2 of tracing that will need to be removed before publishing to crates.io.