Am 03.10.14 16:49, schrieb Andrew Piskorski:
I found two relevant commits in Mercurial, from 2009 and 2012, below.
>From those logs, it looks like what happened is that in 2009, Zoran
removed the platform specific C code and instead made Naviserver call
Tcl_GetTime (somehow). Then in 2012, Gustaf added back the old
Unix-specific gettimeofday() implementation for performance reasons.
no, i did NOT "add back the old Unix-specific gettimeofday()
implementation".
What i did was to extend "configure" to look, if there is gettimeofday()
available
on the system. If it is, it bypasses the call to Tcl_GetTime() to get
the timestamp
via system call. On busy systems, Ns_GetTime() is one of the most
frequent calls, used e.g. for mutex timings, so this makes a difference.
The advantage of using Tcl_GetTime() is to delegate system dependencies
to Tcl.
What does this tell us for your situation:
a) you have most probably not HAVE_GETTIMEOFDAY defined in your
installation, otherwise you have an unresolved external. So, you were
not at all affected by this change of mine!
b) When Tcl_GetTime() is not working on your system than you have a
broken Tcl installation. Does this happen with your self-compiled tcl
version?
In some later mail, you wrote:
./include/nsconfig.h:276:#define SIZEOF_TIME_T 8
That nsconfig.h was created on Linux, but my Windows build uses it
too. Perhaps that is the problem? But how the heck can I generate a
correct version of nsconfig.h for my Windows 7 system?
I have not checked the details of your changes, but as a background:
If one compiles naviserver with -DHAVE_CONFIG_H (the normal case under
unix-like systems),
then ./include/nsconfig.h is used. For MSVC is a set minimal set of
hard-coded
replacement defines included, which might or might not be incomplete or
requires
win7 or 64bit changes. If you are including ./include/nsconfig.h
(generated under linux)
under windows, then you are doomed.
So in LogTime(), I added some simple printf's just before calling
strftime(). ptm->tm_mday and all the other struct members have a
value of -1. That's because in ns_localtime(), localtime_s() returns
an EINVAL = 22 "Invalid argument" error code, and then sets all the
members to -1.
http://msdn.microsoft.com/en-us/library/a442x3ye.aspx
The *tp and *clock values look like a correct time_t count of seconds
since the Unix epoch. So perhaps something is wrong with the only
other argument ther to localtime_s(): &tlsPtr->ltbuf
The page you are citing contains the error conditions, when EINVAL
is returned. The first argument can't be NULL, so clock must be
invalid according to this information.
you might check for testing localtime() as a replacement,
but read as well in the manpage aboutUSE_32BIT_TIME_T
http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx
I am not familiar with the TIME_T mess under windows, check as well
the endless discussions on
http://sourceforge.net/p/mingw/bugs/1973/?page=0
on this issue. Have you tried the suggestion of Maurizio concerning
USE_32BIT_TIME_T?
-g
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
