You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adel Boutros <ad...@live.com> on 2016/04/22 18:24:52 UTC
[Qpid-dispatch] timespec not defined on Windows
Hello,
While compiling Qpid-dispatch on Windows using Visual Studio 2013 64-bit, I
encountered a code related to time which doesn't work under windows.
In *src\server.c* thread_run method, there is a block of code using timespec
which is not defined in Windows
/struct timespec tv;
clock_gettime(CLOCK_REALTIME, &tv);
qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
tv.tv_nsec / 1000000;
qd_timer_visit_LH(milliseconds);/
I have found two ways to solve it:
1) One inspired from Qpid C++ broker
(qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow) but
this will add a dependency to Boost for qpid-dispatch.
2) The other found on Stackoverflow timespec-equivalent-for-windows
<http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
Which one would you find more appropriate?
Regards,
Adel Boutros
www.murex.com
--
View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Jiri Daněk <jd...@redhat.com>.
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 <ad...@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: tross@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
RE: [Qpid-dispatch] timespec not defined on Windows
Posted by Adel Boutros <ad...@live.com>.
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: tross@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Ted Ross <tr...@redhat.com>.
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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Alexandre Trufanow <al...@gmail.com>.
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
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Ted Ross <tr...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Alan Conway <ac...@redhat.com>.
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
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Adel Boutros <ad...@live.com>.
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.
*@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.
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.
*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)
2) getopt.h not available on Windows
3) iovec not available on Windows
4) __thread not available on Windows
5) inline not available on Windows
6) SIGHUP, SIGQUIT not available on Windows
7) Starting a process with a provided user/privileges
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
Regards,
Adel Boutros
www.murex.com
--
View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532p7642630.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2016-04-25 at 15:11 +0200, Adel Boutros wrote:
> Unless you really insist on having a full C compatible code with the
> minimal dependencies. In that case, I will have to write/adapt the
> equivalent code/logic for pthread_mutex_t, pthread_cond_t,
> pthread_rwlock_t and pthread_t on Windows.
>
Hi Adel,
I've been working on concurrent IO alternatives to the proton reactor
in Go, C++ and Ruby. I'm thinking about a C integration with libuv to
give proton concurrent, high-performance IO that is also portable. I
was also considering this project as a possible improved IO driver for
qpid dispatch.
If you are getting dispatch working on windows perhaps we should work
together.
I'm not married to libuv yet, but it seems the front runner. I'm
interested in hearing of gotchas or alternatives.
libuv does provide the basic thread/lock abstractions you mention,
although I can't tell you yet how good they are yet.
Cheers,
Alan.
> >
> > From: adelboutros@live.com
> > To: users@qpid.apache.org
> > Subject: RE: [Qpid-dispatch] timespec not defined on Windows
> > Date: Mon, 25 Apr 2016 14:35:19 +0200
> >
> > Hello Ted,
> > I agree an abstraction level is required but for the time being I
> > am following the TDD approach. So once I have something working, I
> > will refactor it before submitting any patches. I will go with
> > something and only granular to milliseconds as you propose.
> > I am also facing another issue which might require adding a boost
> > dependency and it's related to the pthread library which is not
> > available on Windows. After checking Qpid C++ broker code, it was
> > solved on Windows by using boost thread library.
> > You can check for example https://github.com/apache/qpid/blob/trunk
> > /qpid/cpp/src/qpid/sys/windows/Mutex.h
> > So, how about adding a dependency to boost only for windows
> > platform via Cmake? This way, I can be inspired by Qpid C++ Broker
> > code for threading and no extra dependency is added for
> > Linux/Unix.Or do you propose something better?
> > PS: At some point, it might even be intelligent to extract the
> > common code from Qpid C++ broker, Proton and Dispatcher to create a
> > common "utils" library for threading, logging, daemon/service
> > creation ...
> > Regards,Adel
> >
> > >
> > > Subject: Re: [Qpid-dispatch] timespec not defined on Windows
> > > To: users@qpid.apache.org
> > > From: tross@redhat.com
> > > Date: Fri, 22 Apr 2016 12:35:50 -0400
> > >
> > > Adel,
> > >
> > > First of all, we should create an abstraction for timespec that
> > > is
> > > usable on all platforms and then provide OS-specific
> > > implementations.
> > > Dispatch doesn't currently need time at granularity above
> > > milliseconds.
> > >
> > > To answer your question, I don't want to solve this in a way
> > > that
> > > requires new dependencies in Linux like Boost.
> > >
> > > -Ted
> > >
> > > On 04/22/2016 12:24 PM, Adel Boutros wrote:
> > > >
> > > > Hello,
> > > >
> > > > While compiling Qpid-dispatch on Windows using Visual Studio
> > > > 2013 64-bit, I
> > > > encountered a code related to time which doesn't work under
> > > > windows.
> > > >
> > > > In *src\server.c* thread_run method, there is a block of code
> > > > using timespec
> > > > which is not defined in Windows
> > > >
> > > > /struct timespec tv;
> > > > clock_gettime(CLOCK_REALTIME, &tv);
> > > > qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) *
> > > > 1000 +
> > > > tv.tv_nsec / 1000000;
> > > > qd_timer_visit_LH(milliseconds);/
> > > >
> > > > I have found two ways to solve it:
> > > > 1) One inspired from Qpid C++ broker
> > > > (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and
> > > > outputHiresNow) but
> > > > this will add a dependency to Boost for qpid-dispatch.
> > > > 2) The other found on Stackoverflow timespec-equivalent-for-
> > > > windows
> > > > <http://stackoverflow.com/questions/8583308/timespec-equivalent
> > > > -for-windows>
> > > >
> > > > Which one would you find more appropriate?
> > > >
> > > > Regards,
> > > > Adel Boutros
> > > > www.murex.com
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context: http://qpid.2158936.n2.nabble.com
> > > > /Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
> > > > Sent from the Apache Qpid users mailing list archive at
> > > > Nabble.com.
> > > >
> > > > -------------------------------------------------------------
> > > > --------
> > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > ---------------------------------------------------------------
> > > ------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Chuck Rolke <cr...@redhat.com>.
The Qpid broker sys/windows folder has a lot of model code that could be used for a compatibility layer in dispatch.
https://github.com/apache/qpid/tree/trunk/qpid/cpp/src/qpid/sys/windows
----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: users@qpid.apache.org
> Sent: Monday, April 25, 2016 9:45:46 AM
> Subject: Re: [Qpid-dispatch] timespec not defined on Windows
>
> I don't object to using boost in Windows to provide posix abstractions
> there. I would like to avoid introducing that dependency in Linux
> though if possible.
>
> -Ted
>
>
> On 04/25/2016 09:11 AM, Adel Boutros wrote:
> > Unless you really insist on having a full C compatible code with the
> > minimal dependencies. In that case, I will have to write/adapt the
> > equivalent code/logic for pthread_mutex_t, pthread_cond_t,
> > pthread_rwlock_t and pthread_t on Windows.
> >
> >> From: adelboutros@live.com
> >> To: users@qpid.apache.org
> >> Subject: RE: [Qpid-dispatch] timespec not defined on Windows
> >> Date: Mon, 25 Apr 2016 14:35:19 +0200
> >>
> >> Hello Ted,
> >> I agree an abstraction level is required but for the time being I am
> >> following the TDD approach. So once I have something working, I will
> >> refactor it before submitting any patches. I will go with something and
> >> only granular to milliseconds as you propose.
> >> I am also facing another issue which might require adding a boost
> >> dependency and it's related to the pthread library which is not available
> >> on Windows. After checking Qpid C++ broker code, it was solved on Windows
> >> by using boost thread library.
> >> You can check for example
> >> https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/qpid/sys/windows/Mutex.h
> >> So, how about adding a dependency to boost only for windows platform via
> >> Cmake? This way, I can be inspired by Qpid C++ Broker code for threading
> >> and no extra dependency is added for Linux/Unix.Or do you propose
> >> something better?
> >> PS: At some point, it might even be intelligent to extract the common code
> >> from Qpid C++ broker, Proton and Dispatcher to create a common "utils"
> >> library for threading, logging, daemon/service creation ...
> >> Regards,Adel
> >>
> >>> Subject: Re: [Qpid-dispatch] timespec not defined on Windows
> >>> To: users@qpid.apache.org
> >>> From: tross@redhat.com
> >>> Date: Fri, 22 Apr 2016 12:35:50 -0400
> >>>
> >>> Adel,
> >>>
> >>> First of all, we should create an abstraction for timespec that is
> >>> usable on all platforms and then provide OS-specific implementations.
> >>> Dispatch doesn't currently need time at granularity above milliseconds.
> >>>
> >>> To answer your question, I don't want to solve this in a way that
> >>> requires new dependencies in Linux like Boost.
> >>>
> >>> -Ted
> >>>
> >>> On 04/22/2016 12:24 PM, Adel Boutros wrote:
> >>>> Hello,
> >>>>
> >>>> While compiling Qpid-dispatch on Windows using Visual Studio 2013
> >>>> 64-bit, I
> >>>> encountered a code related to time which doesn't work under windows.
> >>>>
> >>>> In *src\server.c* thread_run method, there is a block of code using
> >>>> timespec
> >>>> which is not defined in Windows
> >>>>
> >>>> /struct timespec tv;
> >>>> clock_gettime(CLOCK_REALTIME, &tv);
> >>>> qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
> >>>> tv.tv_nsec / 1000000;
> >>>> qd_timer_visit_LH(milliseconds);/
> >>>>
> >>>> I have found two ways to solve it:
> >>>> 1) One inspired from Qpid C++ broker
> >>>> (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow)
> >>>> but
> >>>> this will add a dependency to Boost for qpid-dispatch.
> >>>> 2) The other found on Stackoverflow timespec-equivalent-for-windows
> >>>> <http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
> >>>>
> >>>> Which one would you find more appropriate?
> >>>>
> >>>> Regards,
> >>>> Adel Boutros
> >>>> www.murex.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
> >>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Ted Ross <tr...@redhat.com>.
I don't object to using boost in Windows to provide posix abstractions
there. I would like to avoid introducing that dependency in Linux
though if possible.
-Ted
On 04/25/2016 09:11 AM, Adel Boutros wrote:
> Unless you really insist on having a full C compatible code with the minimal dependencies. In that case, I will have to write/adapt the equivalent code/logic for pthread_mutex_t, pthread_cond_t, pthread_rwlock_t and pthread_t on Windows.
>
>> From: adelboutros@live.com
>> To: users@qpid.apache.org
>> Subject: RE: [Qpid-dispatch] timespec not defined on Windows
>> Date: Mon, 25 Apr 2016 14:35:19 +0200
>>
>> Hello Ted,
>> I agree an abstraction level is required but for the time being I am following the TDD approach. So once I have something working, I will refactor it before submitting any patches. I will go with something and only granular to milliseconds as you propose.
>> I am also facing another issue which might require adding a boost dependency and it's related to the pthread library which is not available on Windows. After checking Qpid C++ broker code, it was solved on Windows by using boost thread library.
>> You can check for example https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/qpid/sys/windows/Mutex.h
>> So, how about adding a dependency to boost only for windows platform via Cmake? This way, I can be inspired by Qpid C++ Broker code for threading and no extra dependency is added for Linux/Unix.Or do you propose something better?
>> PS: At some point, it might even be intelligent to extract the common code from Qpid C++ broker, Proton and Dispatcher to create a common "utils" library for threading, logging, daemon/service creation ...
>> Regards,Adel
>>
>>> Subject: Re: [Qpid-dispatch] timespec not defined on Windows
>>> To: users@qpid.apache.org
>>> From: tross@redhat.com
>>> Date: Fri, 22 Apr 2016 12:35:50 -0400
>>>
>>> Adel,
>>>
>>> First of all, we should create an abstraction for timespec that is
>>> usable on all platforms and then provide OS-specific implementations.
>>> Dispatch doesn't currently need time at granularity above milliseconds.
>>>
>>> To answer your question, I don't want to solve this in a way that
>>> requires new dependencies in Linux like Boost.
>>>
>>> -Ted
>>>
>>> On 04/22/2016 12:24 PM, Adel Boutros wrote:
>>>> Hello,
>>>>
>>>> While compiling Qpid-dispatch on Windows using Visual Studio 2013 64-bit, I
>>>> encountered a code related to time which doesn't work under windows.
>>>>
>>>> In *src\server.c* thread_run method, there is a block of code using timespec
>>>> which is not defined in Windows
>>>>
>>>> /struct timespec tv;
>>>> clock_gettime(CLOCK_REALTIME, &tv);
>>>> qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
>>>> tv.tv_nsec / 1000000;
>>>> qd_timer_visit_LH(milliseconds);/
>>>>
>>>> I have found two ways to solve it:
>>>> 1) One inspired from Qpid C++ broker
>>>> (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow) but
>>>> this will add a dependency to Boost for qpid-dispatch.
>>>> 2) The other found on Stackoverflow timespec-equivalent-for-windows
>>>> <http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
>>>>
>>>> Which one would you find more appropriate?
>>>>
>>>> Regards,
>>>> Adel Boutros
>>>> www.murex.com
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
>>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: [Qpid-dispatch] timespec not defined on Windows
Posted by Adel Boutros <ad...@live.com>.
Unless you really insist on having a full C compatible code with the minimal dependencies. In that case, I will have to write/adapt the equivalent code/logic for pthread_mutex_t, pthread_cond_t, pthread_rwlock_t and pthread_t on Windows.
> From: adelboutros@live.com
> To: users@qpid.apache.org
> Subject: RE: [Qpid-dispatch] timespec not defined on Windows
> Date: Mon, 25 Apr 2016 14:35:19 +0200
>
> Hello Ted,
> I agree an abstraction level is required but for the time being I am following the TDD approach. So once I have something working, I will refactor it before submitting any patches. I will go with something and only granular to milliseconds as you propose.
> I am also facing another issue which might require adding a boost dependency and it's related to the pthread library which is not available on Windows. After checking Qpid C++ broker code, it was solved on Windows by using boost thread library.
> You can check for example https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/qpid/sys/windows/Mutex.h
> So, how about adding a dependency to boost only for windows platform via Cmake? This way, I can be inspired by Qpid C++ Broker code for threading and no extra dependency is added for Linux/Unix.Or do you propose something better?
> PS: At some point, it might even be intelligent to extract the common code from Qpid C++ broker, Proton and Dispatcher to create a common "utils" library for threading, logging, daemon/service creation ...
> Regards,Adel
>
> > Subject: Re: [Qpid-dispatch] timespec not defined on Windows
> > To: users@qpid.apache.org
> > From: tross@redhat.com
> > Date: Fri, 22 Apr 2016 12:35:50 -0400
> >
> > Adel,
> >
> > First of all, we should create an abstraction for timespec that is
> > usable on all platforms and then provide OS-specific implementations.
> > Dispatch doesn't currently need time at granularity above milliseconds.
> >
> > To answer your question, I don't want to solve this in a way that
> > requires new dependencies in Linux like Boost.
> >
> > -Ted
> >
> > On 04/22/2016 12:24 PM, Adel Boutros wrote:
> > > Hello,
> > >
> > > While compiling Qpid-dispatch on Windows using Visual Studio 2013 64-bit, I
> > > encountered a code related to time which doesn't work under windows.
> > >
> > > In *src\server.c* thread_run method, there is a block of code using timespec
> > > which is not defined in Windows
> > >
> > > /struct timespec tv;
> > > clock_gettime(CLOCK_REALTIME, &tv);
> > > qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
> > > tv.tv_nsec / 1000000;
> > > qd_timer_visit_LH(milliseconds);/
> > >
> > > I have found two ways to solve it:
> > > 1) One inspired from Qpid C++ broker
> > > (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow) but
> > > this will add a dependency to Boost for qpid-dispatch.
> > > 2) The other found on Stackoverflow timespec-equivalent-for-windows
> > > <http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
> > >
> > > Which one would you find more appropriate?
> > >
> > > Regards,
> > > Adel Boutros
> > > www.murex.com
> > >
> > >
> > >
> > > --
> > > View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
> > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
RE: [Qpid-dispatch] timespec not defined on Windows
Posted by Adel Boutros <ad...@live.com>.
Hello Ted,
I agree an abstraction level is required but for the time being I am following the TDD approach. So once I have something working, I will refactor it before submitting any patches. I will go with something and only granular to milliseconds as you propose.
I am also facing another issue which might require adding a boost dependency and it's related to the pthread library which is not available on Windows. After checking Qpid C++ broker code, it was solved on Windows by using boost thread library.
You can check for example https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/qpid/sys/windows/Mutex.h
So, how about adding a dependency to boost only for windows platform via Cmake? This way, I can be inspired by Qpid C++ Broker code for threading and no extra dependency is added for Linux/Unix.Or do you propose something better?
PS: At some point, it might even be intelligent to extract the common code from Qpid C++ broker, Proton and Dispatcher to create a common "utils" library for threading, logging, daemon/service creation ...
Regards,Adel
> Subject: Re: [Qpid-dispatch] timespec not defined on Windows
> To: users@qpid.apache.org
> From: tross@redhat.com
> Date: Fri, 22 Apr 2016 12:35:50 -0400
>
> Adel,
>
> First of all, we should create an abstraction for timespec that is
> usable on all platforms and then provide OS-specific implementations.
> Dispatch doesn't currently need time at granularity above milliseconds.
>
> To answer your question, I don't want to solve this in a way that
> requires new dependencies in Linux like Boost.
>
> -Ted
>
> On 04/22/2016 12:24 PM, Adel Boutros wrote:
> > Hello,
> >
> > While compiling Qpid-dispatch on Windows using Visual Studio 2013 64-bit, I
> > encountered a code related to time which doesn't work under windows.
> >
> > In *src\server.c* thread_run method, there is a block of code using timespec
> > which is not defined in Windows
> >
> > /struct timespec tv;
> > clock_gettime(CLOCK_REALTIME, &tv);
> > qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
> > tv.tv_nsec / 1000000;
> > qd_timer_visit_LH(milliseconds);/
> >
> > I have found two ways to solve it:
> > 1) One inspired from Qpid C++ broker
> > (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow) but
> > this will add a dependency to Boost for qpid-dispatch.
> > 2) The other found on Stackoverflow timespec-equivalent-for-windows
> > <http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
> >
> > Which one would you find more appropriate?
> >
> > Regards,
> > Adel Boutros
> > www.murex.com
> >
> >
> >
> > --
> > View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
> > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: [Qpid-dispatch] timespec not defined on Windows
Posted by Ted Ross <tr...@redhat.com>.
Adel,
First of all, we should create an abstraction for timespec that is
usable on all platforms and then provide OS-specific implementations.
Dispatch doesn't currently need time at granularity above milliseconds.
To answer your question, I don't want to solve this in a way that
requires new dependencies in Linux like Boost.
-Ted
On 04/22/2016 12:24 PM, Adel Boutros wrote:
> Hello,
>
> While compiling Qpid-dispatch on Windows using Visual Studio 2013 64-bit, I
> encountered a code related to time which doesn't work under windows.
>
> In *src\server.c* thread_run method, there is a block of code using timespec
> which is not defined in Windows
>
> /struct timespec tv;
> clock_gettime(CLOCK_REALTIME, &tv);
> qd_timestamp_t milliseconds = ((qd_timestamp_t)tv.tv_sec) * 1000 +
> tv.tv_nsec / 1000000;
> qd_timer_visit_LH(milliseconds);/
>
> I have found two ways to solve it:
> 1) One inspired from Qpid C++ broker
> (qpid\cpp\src\qpid\sys\windows\Time.cpp: FromEpoch and outputHiresNow) but
> this will add a dependency to Boost for qpid-dispatch.
> 2) The other found on Stackoverflow timespec-equivalent-for-windows
> <http://stackoverflow.com/questions/8583308/timespec-equivalent-for-windows>
>
> Which one would you find more appropriate?
>
> Regards,
> Adel Boutros
> www.murex.com
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-dispatch-timespec-not-defined-on-Windows-tp7642532.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org