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

Future of sync? #8

Open
pdimov opened this issue Oct 9, 2018 · 11 comments
Open

Future of sync? #8

pdimov opened this issue Oct 9, 2018 · 11 comments

Comments

@pdimov
Copy link
Member

pdimov commented Oct 9, 2018

What's the plan about it? It lingers as a submodule on develop but not on master. Is it ever going to be released?

@Lastique
Copy link
Member

Lastique commented Oct 9, 2018

This is totally my fault. I was going to allocate time to write some docs for it and then ask to include it in a Boost release, but never got around to do it. I still want to do it as I think there are useful tools in Boost.Sync, but given the history I'm not sure when I will be able to do it.

We could release it as is, I guess... The tests are running, and as far as I can tell they are mostly passing.

@pdimov
Copy link
Member Author

pdimov commented Oct 9, 2018

Yes but we'll need some sort of a review first, and at least some explanation what it is and what it's for, if only in a README.md form. :-)

@jeking3
Copy link

jeking3 commented Nov 13, 2018

Would the goal be to move synchronization primitives out of Boost.Thread and use these instead? I agree, a README would be nice. :) I can send in a PR for CMT flavor CI if you'd like.

@Lastique
Copy link
Member

Would the goal be to move synchronization primitives out of Boost.Thread and use these instead?

One of the goals of Boost.Sync is to be more lightweight than Boost.Thread and provide more synchronization primitives. Also, compatibility with multiple timing libraries. As to whether Boost.Thread would remove its synchronization primitives, I don't think it was discussed.

I can send in a PR for CMT flavor CI if you'd like.

I think I'll add my own from Boost.Atomic, for example, when the need appears. Thanks for the offer, though.

@jeking3
Copy link

jeking3 commented Nov 13, 2018

The need should be immediate, before anyone uses it. :)

@mloskot
Copy link
Member

mloskot commented Nov 13, 2018

Plus, given that

Boost.Sync was not removed but rather it was never released (yet)

this is really confusing

sync/doc/changelog.qbk

Lines 12 to 17 in e211ea4

[section:changelog Changelog]
[heading 1.0, Boost 1.55]
This is the first release of the library since extraction from __boost_thread__.

@Lastique
Copy link
Member

The need should be immediate, before anyone uses it.

The primary need for CI is for testing PRs. We don't have any.

this is really confusing

I've corrected the changelog wording.

@jeking3
Copy link

jeking3 commented Nov 13, 2018

CI is best if you use it during development, so PRs are not needed after you release. :)

@dvzrv
Copy link

dvzrv commented Mar 15, 2019

Is a release still happening? I'd love to either see this included in boost, or released seperately, so I can devendor it from supercollider.

@Lastique
Copy link
Member

Is a release still happening?

Not in 1.70, unfortunately.

@cmazakas
Copy link
Member

The echoes from the graveyard continue...

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

No branches or pull requests

6 participants