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

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
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> 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.

Reply via email to