On 07.08.11 17:37, Maurizio Martignano wrote:
Dear Gustav,
Thank you.
All's well that ends well...
I'm not sure all the changes I suggested are still in the
codebase... especially the ones in RED
The reason, i have not committed theses two suggested
changes to the code base is that these are incorrect and
would break compilation on the non-windows platforms. Both
suggested changes are in #ifdef branches for compilations
without _WIN32 set (therefore irrelevant for Win32 and
Win64). Please check more carefully first.
-gustaf neumann
It is not up to Aolserver/nsd include system to define
SOCKET as int on Windows.
Thank you again,
Maurizio
*include/ns.h -- 222 **ß***
*#define*O_BINARY 0
// Commented out by M. _Martignano_ on the 05/08/2011
// #define SOCKET _int_
*#define*INVALID_SOCKET (-1)
I removed the define, in Windows (32/64) SOCKET should be
defined somewhere else, and not redefined here.
*include/ns.h -- 674*
// Type changed from _int_ to SOCKET by M. _Martignano_ on
the 05/08/2011
NS_EXTERN SOCKET *Ns_ConnSock*(Ns_Conn*conn);
Self explanatory.
*nsd/conn.c - 615*
// Type changed from _int_ to SOCKET by M. _Martignano_ on
the 05/08/2011
SOCKET
*Ns_ConnSock*(Ns_Conn*conn)
{
Self explanatory
*nsd/nsd.h - 75*
// Conditional compilation clause added by M. _Martignano_
on the 05/08/2011
*#ifndef*_WIN32
*struct*pollfd {
*int*fd;
*short*events;
*short*revents;
};
*#endif*
struct pollfd is already defined
*nsd/nsd.h - 312*
// _int_ trigger[2] changed into SOCKET trigger[2] by M.
_Martignano_ on the 05/08/2011
SOCKET trigger[2]; /* _Wakeup_ trigger socket. */
Well, we all know about this... don't we?
*nsd/nsmain.c -- 633*
// Conditional compilation clause added by M. _Martignano_
on the 05/08/2011
*#ifndef*_WIN32
Tcl_Finalize();
*#endif*
Semantic. Tcl_Finalize never ends on Windows so I removed it.
*nsd/queue.c -- 42*
// Function added by M. _Martignano_ on the 05/08/2011
*#ifdef*_WIN32
*static**double*round(*double*x) { *return*floor(x + 0.5); }
*#endif*
Well believe it or not "round" does not exist. So I ehm
"re-implemented" it based on "floor".
*nspd/listen.c -- 80
*// Type changed from _int_ to SOCKET by M. _Martignano_
on the 05/08/2011
SOCKET sock, new;
Self explanatory
*nspd/pd.h -- 52 **ß***
*#include*<unistd.h>
// Conditional compilation added by M. _Martignano_ on the
05/08/2011
*#ifndef*_WIN32
Well this follows the same reasoning used for ns.h. Anyhow
this is the weakest of all my changes and all the module
should be carefully looked at. I am personally not using
it in my Windows distributions.
*nsperm/nsperm.c -- 583*
// Conditional compilation added by M. _Martignano_ on the
05/08/2011
*#ifndef*_WIN32
*if*(inet_aton(net, &ip) == 0 || inet_aton(slash+1, &mask)
== 0) {
*#else*
*if*(inet_pton(AF_INET,net, &ip) == 0 ||
inet_pton(AF_INET,slash+1, &mask) == 0) {
*#endif*
Well with Micosoft Visual C 10 "inet_aton" seems not to be
there any longer. Luckily we can still rely on "inet_pton".
*From:*AOLserver Discussion
[mailto:AOLSERVER@LISTSERV.AOL.COM] *On Behalf Of *Gustaf
Neumann
*Sent:* 07 August 2011 15:23
*To:* AOLSERVER@LISTSERV.AOL.COM
*Subject:* Re: [AOLSERVER] Aolserver Progress - Some few
examples....
Dear all,
i did some more digging/googling in this issue and i share
the opinion that - at least for the time being -
Tcl_Finalize() could be omitted on windows versions
without too much harm. Some background:
The Tcl manpage says:
*Tcl_Finalize* is similar to*Tcl_Exit* except that it does not exit
from
the current process. It is useful for cleaning up when a process is
finished using*Tcl* but wishes to continue executing, and when*Tcl*
is
used in a dynamically loaded extension that is about to be unloaded.
On some systems*Tcl* is automatically notified when it is being
unloaded, and it calls*Tcl_Finalize* internally; on these systems it
not
necessary for the caller to explicitly call*Tcl_Finalize*. However, to
ensure portability, your code should always invoke*Tcl_Finalize*
when
*Tcl* is being unloaded, to ensure that the code will work on all
plat-
forms.*Tcl_Finalize* can be safely called more than once.
For aolserver, it is questionable for me why we need
Tcl_Finalize() (the primarily purpose for Tcl_Finalize
according to its documentation is that the process wants
to continue without Tcl....), furthermore there seems to
be some magic involved, that "some systems .... call
Tcl_Finalize() ... automatically" (hinting most likely the
windows situation with the assembly code). Since finalize
tries to unload Tcl, there seems to be some race
conditions in this area on windows, at least when there
are still are multiple threads around. E.g. [1] says:
"Because DLL notifications are serialized, entry-point
functions should not attempt to communicate with other
threads or processes. Deadlocks may occur as a result."
Neither aolserver 4.0.10 nor naviserver call
Tcl_Finalize(), so i guess we can live with a 4.5.1+
version under windows without it.
-gustaf neumann
[1] http://msdn.microsoft.com/en-us/library/ms682583.aspx
On 06.08.11 16:28, Maurizio Martignano wrote:
It is me again...
Well I noticed that the change I suggested about
Tcl_Finalize did not make it into CVS HEAD.
If it doesn't go there, I am afraid I will have to anyhow
introduce it myself in my distribution.
I need to have a working system. With that call still in,
the service can't (CANNOT) be stopped gracefully.
This is a matter of testing:
Take the system, make it run with a real OpenACS based
application (how about ]po[, or xowiki....) and see how it
works and see how it interacts with the system... Does it
start? Does it run? Does it stop properly?
For the time being in Windows 64 that function needs to be
out.
Thanks a lot,
Maurizio
Thank you,
Maurizio
*From:*AOLserver Discussion
[mailto:AOLSERVER@LISTSERV.AOL.COM] *On Behalf Of *Gustaf
Neumann
*Sent:* 06 August 2011 10:28
*To:* AOLSERVER@LISTSERV.AOL.COM
<mailto:AOLSERVER@LISTSERV.AOL.COM>
*Subject:* Re: [AOLSERVER] Aolserver Progress - Some few
examples....
Maurizio,
Tcl_Finalize() is supposed to work, and if it does now
work something is still broken in the windows version.
Omitting Tcl_Finalize() is removeing the symptom, not the
cause. It is not unlikely that something else will have
the same problem due to this cause.
When Tcl_Finalize() is not run, the registered exit
handlers are not executed. How serious this is depends on
the exit handlers. You are right, that the "memory leak"
does not matter due to the shutdown. The difference is
like between a graceful and an ungraceful shutdown.
-gustaf
On 05.08.11 16:29, Maurizio Martignano wrote:
Dear Gustav,
I understand your concerns about
Tcl_Finalize... but it is called just when the
process/service is about to end.
Once it ends the OS takes charges and releases the
process/service resources (memory included).
You can make an easy test.... Have Aolserver / nsd running
on a big application... observe the OS resources given to
the process
and released when I finishes. Do this twice: with
Tcl_Finalize on and Tcl_Finalize commented out. And see if
you can find any difference.
Ciao,
Maurizio
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com
<mailto:lists...@listserv.aol.com>> with the
body of "SIGNOFF AOLSERVER" in the email message. You can
leave the Subject: field of your email blank.
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the body of "SIGNOFF
AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
