Hi All, Picking this discussion up again... Seeing no objections, I will start creating tickers/stories to introduce libuv for Apache Celix.
The tickets that directly impact the public api, should be part of the Celix 3.0.0 release. Changes that focus on the internals (event threads, etc) can be done for the Celix 3.0.0,but can also be picked up later. Best regards, Pepijn On Mon, Jul 22, 2024 at 1:25 PM Pepijn Noltes <pepijnnol...@gmail.com> wrote: > > Hi All, > > Ping. > > I like to wait a bit longer before wrapping up this discussion thread. > If we are still in favor of integrating libuv, I will create one or > more tickets for the Celix 3.0.0 release to introduce libuv. > > Note that while updating the Celix event thread to use libuv is an > option, it is not essential for the Celix 3.0.0 release as it does not > impact the external API. > So updating the Celix event thread can be an optional ticket for a > Celix 3.0.0 release. > > Best regards, > Pepijn > > On Mon, Jul 8, 2024 at 7:18 AM Peng Zheng <pengzh...@apache.org> wrote: > > > > On 2024/7/8 02:30, Pepijn Noltes wrote: > > > > > Incorporating libuv into Apache Celix could offer several benefits, > > > including: > > > - Use libuv single threaded event loop for the Apache Celix Event Thread > > > - Threading and thread synchronization abstraction > > > - Signal handling abstract > > > - Socket abstraction > > > - File handling abstraction (OS abstraction) > > > > > > Adopting libuv might not only reduce our codebase but also improve OS > > > abstraction, making Windows support, in the future, more feasible. > > > > Moreover, many high profile open source projects, e.g. > > libcurl/libwebsockets, have good integration with libuv. > > > > As a bonus, both Zhenbao Xu and I are already familiar with libuv, which > > is used extensively in our day job. > > > > > > > > I think it is good to discuss whether integrating libuv is something > > > worth considering. > > > If so, we should determine the appropriate timeline for integration > > > and decide if it should replace existing abstractions like > > > celix_threads.h. > > > > +1 for a try to replace celix_threads.h > > > > > However, it's worth noting that libuv does not provide abstractions > > > for open_memstream or fmemopen. > > > > > > In my opinion, if we proceed with using libuv, it would be ideal to > > > include it in the Apache Celix 3.0.0 release. Otherwise, we might need > > > to introduce two major updates in a short period, which is not ideal. > > > But the downside is that this could postpone an Apache Celix 3.0.0 > > > release. > > > > +1 for including libuv in 3.0.0 release. > > > > > Any thoughts, comments or questions are welcome. > > > > > > Best regards, > > > Pepijn > > > > -- > > Peng Zheng > >
