Re: [naviserver-devel] Naviserver hangs on Windows

[Gustaf N. <ne...@wu...>]

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