qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [Qpid-dispatch] timespec not defined on Windows
Date Wed, 27 Apr 2016 19:29:19 GMT
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. 

> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message