You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
Lastique commentedon 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 commentedon 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 commentedon 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 commentedon Nov 13, 2018
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 think I'll add my own from Boost.Atomic, for example, when the need appears. Thanks for the offer, though.
jeking3 commentedon Nov 13, 2018
The need should be immediate, before anyone uses it. :)
mloskot commentedon Nov 13, 2018
Plus, given that
this is really confusing
sync/doc/changelog.qbk
Lines 12 to 17 in e211ea4
Lastique commentedon Nov 13, 2018
The primary need for CI is for testing PRs. We don't have any.
I've corrected the changelog wording.
jeking3 commentedon Nov 13, 2018
CI is best if you use it during development, so PRs are not needed after you release. :)
dvzrv commentedon 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 commentedon Mar 15, 2019
Not in 1.70, unfortunately.
cmazakas commentedon Jan 18, 2021
The echoes from the graveyard continue...