March 2023 - Boost - lists.preview.boost.org

Re: [boost] boost.asem seeking endorsement
by Peter Dimov 07 Mar '23

07 Mar '23

Klemens Morgenstern wrote: > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. What did Chris suggest people need to use instead of this library when they have the problems it solves?

1 0

Re: [boost] boost.asem seeking endorsement
by Marcelo Zimbres Silva 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 06:05, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. > > It provides the following asio-based synchronization primitives: > > - barrier > - condition_variable > - mutex > - semaphore > > Asio currently has timers & (experimental) channels that can help. > However, I think there is a need for more purpose-made utilities to help > more complex asio-based libraries (requests, redis, mysql et al.) > > Code: https://github.com/klemens-morgenstern/asem > Docs: https://klemens.dev/asem/ > > I'm also not too happy with the name, but so far I only came up with an > acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome. I would also like to endorse this library (although I don't know whether I qualify for endorsing libs or not). Marcelo

1 0

Re: [boost] GSOC director stepping down and replacement
by Niall Douglas 07 Mar '23

07 Mar '23

On 07/03/2023 01:06, Glen Fernandes via Boost wrote: > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. > > If anyone wants to step forward and become the new GSOC administrator, > Boost can keep the program running. > > David has generously agreed to help mentor his replacement until the > transition is complete. Also my thanks to David. You kept at it far longer than I thought you would when you graciously took over the role from me! It's a lot of work, and thanks for continuing its success. Niall

1 0

Re: [boost] GSOC director stepping down and replacement
by Mateusz Loskot 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 02:05, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. Thank you David for the years of your service It's been pleasure collaborate with you over several rounds of GSoC. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] boost.asem seeking endorsement
by Vinnie Falco 07 Mar '23

07 Mar '23

On Mon, Mar 6, 2023 at 11:43 PM Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Asio is already too large anyway and would be better as a few separate libraries Thanks

1 0

Re: [boost] boost.asem seeking endorsement
by Ruben Perez 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 06:05, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. Endorsed. We need this library to do things like pipelining and request throttling in a sane way. I still think the best place for this would be Asio, but if there's not chance to get it in, Boost.Asem is good for me, too. I hereby volunteer as review manager in case you need it. Regards, Ruben.

1 0

Re: [boost] boost.asem seeking endorsement
by Marcelo Zimbres Silva 07 Mar '23

07 Mar '23

Hi, On Tue, 7 Mar 2023 at 08:43, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Can you give more details, he did not express interest by being silent or has he raised design, useability etc. concerns? Or perhaps he is planning to implement them in asio in the future? Regards, Marcelo

1 0

Re: [boost] boost.asem seeking endorsement
by Andrey Semashev 07 Mar '23

07 Mar '23

On 3/7/23 08:04, Klemens Morgenstern via Boost wrote: > > I'm also not too happy with the name, but so far I only came up with an > acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome. AsioSync?

1 0

Re: [boost] boost.asem seeking endorsement
by jepessen＠wteam.it 07 Mar '23

07 Mar '23

Hi. I've a simple question: those are primitives built around asio, and according to the documentation you say "This library is not meant as the default method of synchronization of asio-based apps, but to be used by library developers.", so there's a reason to create a different library instead that trying to merge them directly into boost::asio? Regards Daniele Lupo -----Original Message----- From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Klemens Morgenstern via Boost Sent: Tuesday, March 7, 2023 6:13 AM To: boost(a)lists.boost.org Cc: Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> Subject: [boost] boost.asem seeking endorsement Heya Boost Community, I am seeking endorsement for my boost.asem library. It provides the following asio-based synchronization primitives: - barrier - condition_variable - mutex - semaphore Asio currently has timers & (experimental) channels that can help. However, I think there is a need for more purpose-made utilities to help more complex asio-based libraries (requests, redis, mysql et al.) Code: https://github.com/klemens-morgenstern/asem Docs: https://klemens.dev/asem/ I'm also not too happy with the name, but so far I only came up with an acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost.asem seeking endorsement
by Klemens Morgenstern 07 Mar '23

07 Mar '23

Heya Boost Community, I am seeking endorsement for my boost.asem library. It provides the following asio-based synchronization primitives: - barrier - condition_variable - mutex - semaphore Asio currently has timers & (experimental) channels that can help. However, I think there is a need for more purpose-made utilities to help more complex asio-based libraries (requests, redis, mysql et al.) Code: https://github.com/klemens-morgenstern/asem Docs: https://klemens.dev/asem/ I'm also not too happy with the name, but so far I only came up with an acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome.

1 0