qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Trufanow <alexandre.trufanow...@gmail.com>
Subject Re: [Qpid-dispatch] timespec not defined on Windows
Date Thu, 28 Apr 2016 09:16:39 GMT
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?

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.

A

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message