You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by nm...@gmx.es on 2018/09/06 11:26:05 UTC
Building qpid proton proactor on linux 2.6...
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Building qpid proton proactor on linux 2.6...
Posted by Ted Ross <tr...@redhat.com>.
timerfd can be fairly easily replaced with a socketpair, where one
socket is used in the poll/select and the other is used to signal
activation. To wake up the poll/select, write a character into the
signal socket. You will need to be sure to read the characters out of
the select socket to make sure you don't get a full buffer and
back-pressure.
-Ted
On Thu, Sep 6, 2018 at 7:26 AM, <nm...@gmx.es> 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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Building qpid proton proactor on linux 2.6...
Posted by Alan Conway <ac...@redhat.com>.
On Thu, Sep 6, 2018 at 3:53 PM, Cliff Jansen <cl...@gmail.com> 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, <nm...@gmx.es> 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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Building qpid proton proactor on linux 2.6...
Posted by Cliff Jansen <cl...@gmail.com>.
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.
On Thu, Sep 6, 2018 at 4:26 AM, <nm...@gmx.es> 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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org