On Thu, Sep 6, 2018 at 3:53 PM, Cliff Jansen wrote:
> Have you tried the libuv proactor implementation for Proton-C? See
> qpid-proton/c/CMakeLists.txt.
>
> The current release of libuv claims to be fully supported on "Linux >=
> 2.6.32 with glibc >= 2.12".
>
> If libuv works for you, that might be the easiest solution.
>
+1 to that. We have specific proactors for linux (assumes timerfd and
epoll) and iocp (windows) but we're hoping that libuv will be good-enough
everywhere else. In principle you can write new proactor impls for specific
platforms but if libuv can do it (or be fixed/improved to do it) then we'd
prefer to offload the porting work to the libuv folks. The reason for
specific linux/epoll proactors is more about avoiding dependencies than
performance, libuv should perform well (although it hasn't had as much
testing)
> On Thu, Sep 6, 2018 at 4:26 AM, wrote:
> >
> > Hi,
> >
> > I am trying to port a project which was implemented using
> qpid-proton-cpp from a fairly recent Fedora linux kernel to an older RHEL
> linux 2.6.
> >
> > The older kernel is required because the end user unfortunately only
> runs the older linux kernel, and due to company policy they cannot upgrade
> in the near future.
> >
> > Unfortunately when we try to build on linux kernel 2.6 there are
> dependency issues which relate to the older kernel not including support
> for timerfd which is used in qpid-proton-proactor.
> >
> > We did also encounter some other build issues with some of the cpp
> templates in proton-cpp due to bugs in the older GNU compiler version which
> we fixed using workarounds, but getting the proactor to work on the older
> kernel looks like it will be less than trivial without timerfd.
> >
> > I do see what appears to be an older implementation for IO etc named
> reactor as opposed to proactor in the proton c implementations, but
> unfortunately the cpp container implementation which we are using does not
> seem to have an implementation using reactor instead of proactor?
> >
> > Is there any way around this - is it possible to use container without
> having timerfd support in the kernel?
> >
> > Performance isn't important for us in this so a simple socket read loop
> would be fine - just I am not sure how to shoehorn that into what we have
> already implemented using container...?
> >
> > Thanks
> > N
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
