Giter Site home page Giter Site logo

najamelan / async_nursery Goto Github PK

View Code? Open in Web Editor NEW
49.0 49.0 6.0 119 KB

Primitive for structured concurrency.

Home Page: https://docs.rs/async_nursery

License: The Unlicense

Rust 96.46% Shell 3.54%
async executor-agnostic executors rust structured-concurrency

async_nursery's People

Contributors

hnasar avatar najamelan avatar touilleman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

async_nursery's Issues

`tracing` feature has an implicit dependency on `futures` crate which should be declared

If the tracing feature of this crate is enabled without also enabling the implementation feature (e.g. default-features = false):

error[E0432]: unresolved import `futures`
 --> /home/teohhanhui/.cargo/registry/src/github.com-1ecc6299db9ec823/async_nursery-0.4.0/src/tracing.rs:5:2
  |
5 |     futures         :: { FutureExt                              } ,
  |     ^^^^^^^ use of undeclared crate or module `futures`

Use shorter lifetimes

Right now, I use the function: fn nurse( &self, fut: impl Future<Output = Out> + Send + 'static ) -> Result<(), NurseErr>; This unfortunately means I can't use references in my async fn with a lifetime less than 'static, which is quite inconvenient.

I'm not really sure of the complexity of changing that, but I'd appreciate any thoughts you have on it.

Possibility to split the core into a separate crate?

For example, in my library I have an interval function which takes a Nurse<_> and calls NurseExt<_> methods on it:

https://github.com/teohhanhui/callbag-rs/blob/d0a7523018854a44a3c4d1687fefa893afa3beb0/src/interval.rs

Currently, every user of my library would be forced to bring in a whole lot of dependencies, even if they don't use this interval function.

This is because async_nursery depends on async_executors and futures.

From what I can see, if we were to split into a crate such as async_nursery_core, which includes:

It only needs to have these dependencies:

  • futures-channel:
    • TrySendError
  • futures-task:
    • FutureObj
    • LocalFutureObj
    • SpawnError

And we shouldn't run afoul of coherence rules, since struct Nursery<_, _> and struct NurseryStream<_, _> will both still be defined in the async_nursery crate.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.