Re: [Qpid-dispatch] timespec not defined on Windows

[Jiri Daněk <jd...@redhat.com>]

Hi folks,

I've submitted a PR dealing with undefined timespec on Windows. It takes
advantage of the fact that in the meantime, Proton 0.30.0
introduced pn_proactor_now_64 in
https://issues.apache.org/jira/browse/PROTON-2030, which can be used to
provide monotonic timestamps on all (Proton-supported) platforms. That
obviously leaves quite a lot to be yet resolved, such as threading, but
it's a start.

https://github.com/apache/qpid-dispatch/pull/1297

On Mon, May 9, 2016 at 3:35 PM Adel Boutros <ad...@live.com> wrote:

> Hello guys,
> Unfortunately, during the period I was off, the team descoped compiling
> Qpid-dispatch on Windows due to time constraints and arrival of tasks with
> higher priorities.
> So Neither Alexandre nor myself will be able to work on this anymore at
> least in the near future.
> Nevertheless, the issues I reported are all the issues I could find.
> Sorry for the inconvenience,Adel
>
> > Subject: Re: [Qpid-dispatch] timespec not defined on Windows
> > To: users@qpid.apache.org
> > From: tross@redhat.com
> > Date: Thu, 28 Apr 2016 09:04:47 -0400
> >
> >
> > On 04/28/2016 05:16 AM, Alexandre Trufanow wrote:
> > > Hi guys,
> > >
> > > I'm taking over Adel's work on porting the dispatcher, I have a few
> > > additional comments to make.
> > >
> > >>>> *@Chuck,*
> > >>>> I took a look at Qpid C++ broker model but the main issue is it is
> > >>>> C++
> > >>>> oriented whereas the dispatcher is mainly C. I tried to switch the
> > >>>> compiler
> > >>>> of Visual studio to C++ and got a lot of errors. So I prefer to stay
> > >>>> on a
> > >>>> full C approach for the time being to gain time.
> > >>>
> > >>>
> > >>> For dispatch that makes sense. We want to keep the main dispatch
> > >>> codebase in portable C and minimise the platform-specific variations.
> > >>>
> > >
> > > To make things clear, the idea is to use the C++ compiler of MSVC
> instead
> > > of the C one. This is the strategy used by proton for compiling on
> windows,
> > > as C99 support is much better with the C++ compiler. Unfortunately,
> this
> > > approach adds some ugliness to the code (notably extern "C" {} blocks
> in
> > > the header files). This does have advantages though, such as support
> for
> > > the inline keyword.
> > >
> > >>>>
> > >>>> *@Alan,*
> > >>>> I am actually in the phase of discovering what are the issues to
> make
> > >>>> the
> > >>>> dispatcher compile and run on Windows. So I haven't really focused
> on
> > >>>> finding the best alternatives.
> > >>>> Nevertheless, I took a quick look at the libuv and its
> implementation
> > >>>> and I
> > >>>> find it very similar to what I was going to code on Windows. So it
> is
> > >>>> worth
> > >>>> checking. My other alternative was to use an adapted in-house code.
> > >>>
> > >>>
> > >>> Great. I'm going to give libuv a shot, if it works it might kill
> > >>> several birds with one stone (Linux, Posix, Darwin, Windows and
> > >>> Solaris) If it doesn't work we can fall back to per-platform
> solutions.
> > >>> However I'm keen to get an updated IO driver into dispatch with the
> > >>> goal that any IO driver we build for proton can slot in to dispatch
> > >>> without changing dispatch. That way we'll get wider testing &
> > >>> optimization of common IO code than if dispatch has its own.
> > >>>
> > >
> > > I agree that using libuv would allow for better IO compatibility.
> However in
> > > order to fully take advantage of this, it should be added as a
> dependency on
> > > Linux. It doesn't make sense to have two competing implementations of
> the
> > > OS specific code if one supports all platforms.
> > >
> > > @Ted: You have previously stated that you don't want to add any
> external
> > > dependencies for Linux, is adding libuv acceptable for you in this
> case?
> >
> > What I said was that I didn't want to introduce a Boost dependency in
> > Linux to support Windows.  If libuv is an effective way to bring an
> > epoll driver into Linux, then I think that would be acceptable.  This
> > would add value to both platforms.
> >
> > >
> > > For now I am working on the other parts of the code which are
> incompatible.
> > >
> > > Another thing which has come up is implicit conversion of int types.
> MSVC
> > > 2013 throws a lot of warnings related to implicit conversions between
> types
> > > (unsigned int, size_t, pointer math). A lot of these errors are
> probably fixed
> > > by changing types to size_t.
> > >
> > > Are there any places in the code where we should watch for the
> > > performance impact of these changes? Specifically some places such as
> > > qd_composite_t use uin32_t explicitly.
> >
> > The explicit uint32_t vales in qd_composite_t are matched to 32-bit
> > length and count fields defined in the AMQP specification.  We should
> > take these instances on one-by-one.  I'd be happy to help with this.  I
> > do have access to the MSVC environment.
> >
> > >
> > > A
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>



-- 
Mit freundlichen Grüßen / Kind regards
Jiri Daněk