On 04/27/2016 03:29 PM, Alan Conway wrote:
On Tue, 2016-04-26 at 01:04 -0700, Adel Boutros wrote:
Hello,
*@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.
*@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.
Regarding the approach for Proton and dispatcher, we have to test it
on the
different OSes to make sure it is compatible (My biggest doubt is
always
Solaris although they say they support it). In my work environment,
we will
have to make sure Proton compiles with Visual Studio 2008 on Windows,
gcc3.4
on Linux and Sunstudio 12.1 on Solaris. As for the dispatcher, there
are no
problems in using more updated versions of the compilers and gcc for
Solaris.
Unfortunately, I will be on vacation starting this afternoon and I
will be
back on the 9th of May. On my return, I will try to introduce libuv
in the
code and test it if no one would have done it by then. I will ask ask
my
colleagues if they can check.
Ping us when you get back, hopefully we'll have made some progress.
*Summary of issues faced on Windows*
1) CMakeLists
a) dl_lib, rt_lib pthread_lib not available on Windows
(CMakeLists.txt)
b) install needs ARCHIVE and RUNTIME properties
(src/CMakeLists.txt)
CMake has some solutions for this stuff, check the proton CMakeLists.
I'm not a good reference.
2) getopt.h not available on Windows
3) iovec not available on Windows
We will need platform shims for each of those. iovec isn't hard to
fake, I think the GNU libraries have a getopt compat wrapper on Windows
or we can just implement option parsing separately for each.
I don't believe that Qpid Dispatch Router uses iovec. That is in the
library to serve other non-router purposes. It can probably just be
removed.
4) __thread not available on Windows
Same as __declspec(thread) We can use a macro like qpid/sys/Thread.h -
it's C compatible.
5) inline not available on Windows
I'd guess we can just drop it. Any compiler with half a brain will
inline those functions anyway.
6) SIGHUP, SIGQUIT not available on Windows
7) Starting a process with a provided user/privileges
Yep the whole daemon process/windows service thing is entirely
different. You can get some ideas from qpid but they'll have to be
translated from C++ to C. I would say the whole server main() (getopt,
fork, signals, daemonization etc.) will probably be completely
different for windows and posix.
8) Limited support of C99 for Visual Studio 2013
a) arrays cannot have length defined in a variable (int len = 3;
int
char[len]; doesn't work)
9) unistd.h not available on Windows
10) timespec not available on Windows
11) pipe, fork not available on Windows
I have a workaround/fix for most of these issues though
Good stuff. Enjoy your vacation and we'll talk when you get back.
---------------------------------------------------------------------
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]
