Rayon 1.0 on Feb 14


Rayon is planning its 1.0 release for Valentine’s Day, Feb 14, 2018 – and we would like your feedback!


Following up on the great work that was done during the Libz Blitz, Rayon now has a
fairly concrete set of things to get done before the 1.0 release. Most of the tasks are writing documentation of one sort or another, but
there are also a few remaining API questions that ought to be settled first. We have decided to shoot for Valentine’s Day (Feb 14) as our 1.0 release date. So that gives us about 6 weeks to get that work done.

Planning meetings

One of the things that we would like to do is to try and get more people involved in the design and maintenance of Rayon. To that end, we are going to hold two public meetings in the runup to Rayon 1.0:

  • January 24th (T-3 weeks till release)
  • February 7th (T-1 week till release)

These meetings will review the state of the bugs and make sure we are on track for release. If you are able, they are free for anyone to attend. Exact times to be announced.

Do you think we overlooked something?

If you have concerns about Rayon’s API that you think should be addressed before 1.0, now is the time to speak up! Feel free to leave comments here in this thread. Alternatively, you can open an issue on the Rayon repo (and cc @nikomatsakis and @cuviper to help draw our attention to it).


Was there ever a discussion about returning a JoinHandle-like structure from rayon::ThreadPool::spawn such that one could join on it like a std::thread::Thread? Is this even possible?

It was discussed, and I even had a PR that did it. However, I wound up backing off from that approach for two reasons.

First, I wanted to pursue futures integration. Basically, if you think about it, we are re-creating futures with this interface and I thought it would be better to try and use the standard traits.

Another problem is that blocking until a task is done carries deadlock risk. This is also true when using futures, even with rayon_wait (which should probably be removed).

In any case, while the futures crate requires more work, I still think that futures integration is the right way to approach this, versus rolling our own variant.

1 Like

I suppose we should set a time and venue here!

For the time, Niko and I are based in EST and PST, respectively. If anyone has time preferences that will fit those timezones, please speak up - otherwise we’ll just choose something ourselves. I could set up a Doodle or something if that would help.

For the venue, my suggestion is that I can host it on BlueJeans. This supports video and recording (for those that can’t make the time), as well as guest access so folks don’t need an account. Test it here if you like. (I suggest canceling the app download and just “join with browser”.) Other options would be fine with me too, like Google Hangouts.

1 Like

Let’s say 10AM PT == 1pm ET

1 Like

If it’s not already locked in, how about 11AM PT?

Otherwise I personally can make 10AM work.

11AM is also fine with me – @nikomatsakis?

We’re going to keep the same time, 10AM Pacific == 18:00 UTC.

Here’s my BlueJeans link. If that doesn’t work out, we’ll post an alternative here.

Seems to be working for me in Firefox :+1:

Notes and things in this Dropbox Paper Document

@nikomatsakis, @KodrAus, @jwass, and anyone else interested…

Same time and place?

That sounds good to me :+1:

Ah sorry I’m going to have to pull out today, but am keen ro keep up with the results of today’s catchup!