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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
