Dear Andrew and Gustaf,
In due time, when you both are confident on the status of Naviserver
on Windows, I would try it inside my Windows-OpenACS distribution.
First of all I would try it in few installations running on the machines I
have in my offices, then once I see it they are running fine and everything
I have now still behave the same, I would make the new version of the
distribution available.
Is that OK with you?
Maurizio
-----Original Message-----
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 08 October 2014 18:39
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] Naviserver hangs on Windows
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
------------------------------------------------------------------------------
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
