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 <adelbout...@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: tr...@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-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 > > > -- Mit freundlichen Grüßen / Kind regards Jiri Daněk