Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WorkQueue implementation #13227

Closed
wants to merge 3 commits into from
Closed

WorkQueue implementation #13227

wants to merge 3 commits into from

Conversation

mgax
Copy link

@mgax mgax commented Mar 31, 2014

A simple worker queue.

Example

use std::task;

// Create the queue
let (queue, dispatcher) = WorkQueue::<int, int>();

// Spawn a dispatcher thread
task::spawn(proc() { dispatcher.run(); });

// Spawn 10 workers
for _ in range(0, 10) {
    let worker = queue.worker();
    task::spawn(proc() { worker.run(|arg| arg + 2); });
}

// Execute jobs on the queue
let answers: ~[int] =
    range(0, 1000)
    .map(|n| queue.push(n))
    .map(|rv| rv.recv())
    .collect();
assert_eq!(answers, range(2, 1002).collect());

// The dispatcher and workers are shut down when `queue` goes out ouf scope

Jobs can be queued from other tasks:

let proxy = queue.proxy();
assert!(task::try(proc() {
    assert_eq!(proxy.push(5).recv(), 7);
}).is_ok());

@jdm
Copy link
Contributor

jdm commented Mar 31, 2014

cc @pcwalton

@thestinger
Copy link
Contributor

In my opinion, we should have something like the Thread Building Blocks task graphs, although it would be much easier to just do a tree to start with. The building blocks for work stealing are there after all.

@brson
Copy link
Contributor

brson commented Mar 31, 2014

We need to not take this step lightly. Rust is almost powerful enough now to express a lot of cool stuff and there are multiple competing work stealing implementations in development. This subject is probably RFC worthy.

@@ -0,0 +1,278 @@
// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this say 2014?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, I blindly copied that from another file. Fixed.

@nikomatsakis
Copy link
Contributor

On Mon, Mar 31, 2014 at 12:58:56PM -0700, Brian Anderson wrote:

We need to not take this step lightly. Rust is almost powerful
enough now to express a lot of cool stuff and there are multiple
competing work stealing implementations in development. This subject
is probably RFC worthy.

+1

@alexcrichton
Copy link
Member

Thank you for this work, I think it's great that there's effort behind adding a work queue!

I agree with @brson though, that this is a broad enough topic that it warrants an RFC. Work queues have many flavors to them, and I think that an RFC is necessary to discuss the tradeoffs and discuss design for the one inside of libsync. I would recommend starting by gathering more knowledge about existing work queues in Rust and see how they play into this design. I would be more than willing to talk about the "work queue" in libgreen, and I'm sure @pcwalton would love to talk about the work queue work that he's done in Servo.

Our RFC process is documented at the rfcs repo.

notriddle pushed a commit to notriddle/rust that referenced this pull request Sep 20, 2022
Restructure `find_path` into a separate functions for modules and non-module items

Follow up to rust-lang/rust-analyzer#13212
Also renames `prefer_core` imports config to `prefer_no_std` and changes the behavior of no_std path searching by preferring `core` paths `over` alloc

This PR turned into a slight rewrite, so it unfortunately does a few more things that I initially planned to (including a bug fix for enum variant paths)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants