On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
> the advantage of approach 2 (disable mutex timings, use ) is that this
> works for 32bit and 64 bit, while (1)
> works most likely only for 64bit (if i look at the constant).
No, I'm confident that the approach using EPOCH_BIAS works just fine
on 32-bit Windows, because in AOLserver 4.0.7 and 4.0.8 that is the
ONLY implementation of Ns_GetTime on Windows, and I ran those versions
of AOLserver for years on Windows XP 32-bit.
Calls to Ns_GetTime() are very common, so AFAICT, for those AOLservers
to work at all, that EPOCH_BIAS code had to be working fine on 32-bit
Windows XP. The only other alternative is that AOLserver was somehow
magically calling an entirely different function instead of
Ns_GetTime(), which I judge as very unlikely.
> The mutex timings is an additional feature in naviserver, so at least
> for the time being, one can life without that.... and with the
> deeper knowledge, we might be able to activate this later again.
Ah, I didn't realize that. I should turn them back off for Windows in
my fork then?
> The problem seems to be: DllMain() calls certain functions
> before the normal entry point main() is called, which initializes
> tcl etc. The Windows man page [1] says:
Interesting. And of course DllMain() only exists on Windows. But,
why do we need DllMain() at all? I assume we DO need it of course, I
just don't understand the design differences between Naviserver's
pthread and winthread support. Both Posix and Windows use
Nsthreads_LibInit(), but DllMain() seems to be an extra layer not
present for Posix.
> > changing the Ns_Time.sec (in nsthread.h) to be time_t rather than long
> > fixes nearly everything.
>
> The reason, naviserver uses 2x long in Ns_Time is probably due to
> Tcl, using:
AFAICT, using long is just wrong, and Tcl and Naviserver both should
have been using time_t for many years now. I'm not sure when time_t
was invented and standardized, but since then it's been what Unix and
Windows both use.
So what am I missing? Why did the Tcl maintainers stick with long for
Tcl_Time.sec? It could just be a holdover from before time_t existed
or really mattered, but perhaps they had a better for keeping it as a
long.
> 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.
Could be. I will try the no-mutex-timings and Ns_GetTimeFromTcl()
approach again, this time with Ns_Time.sec changed back to type long
rather than time_t.
> Probably, i should get a windows installation running, but
> the setup costs are quite high in terms of time and lack
> on windows-knowlege on my side.
Yeah. Maybe the Docker stuff Stephen showed us would make it easier?
Definitely see the notes I sent a while back on exactly what Microsoft
software to install. All the main stuff you need is available for
free but figuring out WHAT you're supposed to install is not easy.
Btw, if you do go that route, be aware that I am using
nmake -f Makefile.win32
for building and cleaning, but NOT for installing Naviserver. I have
not debugged the install commands of those two *.win32 makefiles at
all, because I have my own old Tcl script ("win32-install-nsd.tcl")
for intalling on Windows, which I was able to quickly adapt to
Naviserver.
If you want that install script let me know. I haven't added it to
Mercurial yet because it is in CVS, and I'd like to nicely retain its
full history it, but haven't looked up how to best do that yet.
--
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
