Gustaf, my fork should be suitable for merging back into naviserver/naviserver now.
On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote: > So at least, when using Tcl_GetTime(), > which returns the time as Tcl_Time, everything should be > fine. Note, that in your native time implementation, you > assign to timePtr->sec with (time_t), which might be > part of the problem you are experiencing. Your bugfix aecf84685138 is of course the the key change: https://bitbucket.org/naviserver/naviserver/commits/aecf8468513892cb6dc241f09a9e8ad2dcd57793 Now with that, the only remaining problem is using Ns_GetTimeFromTcl() (the "platform-independent" approach) while mutex timings are turned on. Using Ns_Time.sec as long vs. time_t made no difference for that problem, which makes sense given your explanation of the problems of calling Tcl from inside DllMain(). All other combinations appear to work fine, regardless of whether Ns_Time.sec is long or time_t. To summarize, we've explored these four binary state changes on 64-bit Windows 7: 1. LogTime() long/time_t arg passing bug (aecf846) Fixed vs. Broken. 2. Mutex timing ON vs. OFF. 3. Ns_Time.sec is type long vs. time_t. 4. Ns_GetTime() uses Ns_GetTimeFromTcl() vs. Ns_GetTimeFromWindowsFileTime(). Some of the combinations of those states or of interest for deciding what we should do with the Naviserver codebase. We want to know if Naviserver seems (at least trivially) to run ok, vs. when its behavior is clearly very bad. Below, I will write each combination of states as a four-tuple, e.g. "Broken, On, long, FromTcl", with the result (Ok or Bad) to the left. In earlier emails, I covered these combinations: Bad: Broken, On, long, FromTcl Immediate hang on startup. Bad: Broken, On, time_t, FromTcl Immediate hang on startup. Bad: Broken, Off, long, FromWindowsFileTime Slightly later failure during startup, EINVAL from localtime_s(). Ok: Broken, Off, time_t, FromTcl Ok: Broken, On, time_t, FromWindowsFileTime Today I (manually) tested these combinations and found that: Ok: Fixed, Off, time_t, FromWindowsFileTime Ok: Fixed, On, time_t, FromWindowsFileTime Ok: Fixed, Off, time_t, FromTcl Ok: Fixed, On, time_t, FromTcl Ok: Fixed, Off, long, FromWindowsFileTime Ok: Fixed, On, long, FromWindowsFileTime Ok: Fixed, Off, long, FromTcl: Bad: Fixed, On, long, FromTcl Immediate hang on startup. So clearly we do NOT need to make Ns_Time.sec a time_t. Separately, I've asked tcl-c...@lists.sourceforge.net why it is a long in Tcl. In Ns_GetTime(), if we use Ns_GetTimeFromWindowsFileTime(), we can turn on mutex timing if we want. If we instead use Ns_GetTimeFromTcl() we must keep mutex timing turned off. Since Gustaf seems to prefer Ns_GetTimeFromTcl() over mutex timing, I've gone with that combination in my fork as well. -- Andrew Piskorski <a...@piskorski.com> ------------------------------------------------------------------------------ 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
