On Sun, Oct 05, 2014 at 09:31:31PM +0200, Gustaf Neumann wrote: > On busy systems, Ns_GetTime() is one of the most > frequent calls, used e.g. for mutex timings, so this makes a difference.
Yes, so it's better for performance reasons, like I said. You may have written that small paragraph of code from scratch, but it is still true that inside the ifdef you added, the code calling gettimeofday() is essentially identical to what AOLserver used for many years. This is all fine, I see no problems with that code. > What i did was to extend "configure" to look, if there is gettimeofday() Actually, and strangely, my Naviserver on Windows appeared to NEVER call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was true or false! I tried it both ways. I can't explain that; perhaps I was merely confused. But what is much more important to me, is that running the final "portable" Tcl-dependent code at the end definitely triggered a serious bug, making Naviserver unusable. > 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? I do not know whether Tcl_GetTime() is working correctly in ActiveTcl 8.5 on Windows 7 64-bit or not. I will try something to verify that. Right now all I can say for sure is that funny indirect way that Naviserver calls Tcl_GetTime() in Ns_GetTime() fails horribly on my Windows build. So far I've never compiled Tcl on Windows 7 myself. I may try that soon to help with the debugging, but so far I've been exclusing using ActiveTcl 8.5. I strongly suspect that ActiveTcl is compiled correctly, but perhaps I am somehow linking against it incorrectly, or using incompatible build options, or something like that. > >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. No, the clock value is not invalid, I already checked that and it is a correct count of seconds since the Unix epoch. The problem must lie either in the other argument, or in something entirely separate and out of band (e.g., build options). > on this issue. Have you tried the suggestion of Maurizio concerning > > USE_32BIT_TIME_T? I have not tried using it yet, but maybe I should. Previously, I wasn't sure if Maurizio was recommending it or warning against it. (I see now that he recommends using it.) My previous experience with AOLserver 4.0.x on Windows was with 32-bit Windows, which would have natively used 32-bit time_t. So perhaps forcing my 64-bit build to use 32-bit time_t would be useful. -- Andrew Piskorski <a...@piskorski.com> ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
