Andrew, these are good news!
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). 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.
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:
* Warning* There are serious limits on what you can do in a DLL entry
point.
... not without a reason. It seems, that nn the windows side, one
has to be very careful, what is called inside these routines, since
all calls to Tcl* are potentially unsafe.
> 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:
typedef struct Tcl_Time {
long sec; /* Seconds. */
long usec; /* Microseconds. */
} Tcl_Time;
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.
I have to look at this closer before i have a better seeing
of consequences of changing the types in Ns_Time, i would
certainly prefer to stick to the Tcl conventions, since we depend
strongly on tcl behavior all over the place.
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.
All together, things look already much better.
-g
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx
Am 08.10.14 07:14, schrieb Andrew Piskorski:
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
Please something more to try: to provide some potential evidence for
my "too early for tcl calls" hypothesis, i've deactivated for the
time being the mutex time monitoring for windows, since the earliest
calls are from mutex calls. Can you check when possible, whether
Tcl_GetTime() can be used now inside Ns_GetTime()?
Gustaf, I think you were on to something there.
In my fork I turned the Windows mutex timings back on, because they
work now. However, they ONLY work correctly when Ns_GetTime() is
using the old-style AOLserver code with EPOCH_BIAS, etc.
If I change Ns_GetTime() back to using the Ns_GetTimeFromTcl()
"platform-independent" code, then the server immediately hangs on
startup in TclpGetDate(), just like in my original email on 10/3.
To summarize, there seem to be two combinations that work ok (so far):
1. Ns_GetTime() uses EPOCH_BIAS calculation, normal mutex timings in
nsthread/mutex.c turned on.
2. Ns_GetTime() uses Ns_GetTimeFromTcl(), mutex timings in
nsthread/mutex.c DISABLED.
With either of those combinations, Naviserver will start up and then
shut down, which is really all I've tested.
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
------------------------------------------------------------------------------
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
