pthreads and AOLserver

[Sep Ng]

I've been poking around with how AOLserver handles ns_threads and wanted to raise the questions pertaining to memory leaks.
From the pthread_create man page...

A thread may either be joinable or detached.  If a thread is joinable, then
       another thread can call pthread_join(3) to wait for the thread to terminate
       and fetch its exit status.  Only when a terminated joinable thread has been
       joined are the last of its resources released back to the system.

Does this mean that if I don't use ns_thread join, the resources and tcl interpreter of the thread spawned by ns_thread begin will not get released?

If someone would kindly definitively answer this for me, that would be well appreciated.

Regards.

[Maurizio Martignano]

Dear Sep Ng,

                Memory leaks do exist in the majority of Web Servers (Aolserver included). This is a sad fact. Instead of trying to fix these leaks a better and cheaper strategy could be to have a daily restart of your web/application server.

 

In case you need continuous operation, you can set up a cluster of web/application servers where each one of them does a restart every now and then to cope with the memory leaks, in any case the cluster never stops being available. 

 

I created several installations of this type, see for instance:

http://www.spazioit.com/pages_en/sol_inf_en/distributed-sandbox-for-application-servers_en/

 

Another need, which now unfortunately emerged in my area is the requirement to have redundant installations, capable of resisting to catastrophic events. You can find something about this in here:

http://www.spazioit.com/pages_en/sol_inf_en/disaster_recovery_solutions_en/

 

I hope you find this information useful.

 

Ciao,

Maurizio

[Sep Ng]

Thanks Maurizio.  I will review the links you have posted.

I wanted to raise this question to everyone.  It seems to me that ns_thread wait and join have the same functionality.  If that is the case, why the insistence of defining the 'wait' command?

[Maurizio Martignano]

The semantics for join and wait are different.

 

thread::join id

This command waits for the thread with ID id to exit and then returns it's exit code. Errors will be returned for threads which are not joinable or already waited upon by another thread. Upon the join the handle of the thread has gone out of scope and should not be used any more.

 

thread::wait

This enters the event loop so a thread can receive messages from the thread::send command. This command should only be used within the script passed to the thread::create. It should be the very last command in the script. If this is not the case, the exiting thread will continue executing the script lines pass the thread::wait which is usually not what you want and/or expect.

    set t1 [thread::create {

        #

        # Do some initialization work here

        #

        thread::wait ; # Enter the event loop

    }]

 

I hope that helps,

Maurizio

[Gustaf Neumann]

the subcommands "ns_thread wait" and "ns_thread join" are implemented with the identical c-code
(calling Ns_ThreadJoin(), which calls straigth pthread_join()).
aolserver has now own thread semantics.

"insistence"? You mean, why there are 2 commands? I could only guess: A few commands
are there solely for backward compatibility.

-gustaf neumann

[Sep Ng]

Thank you all for your insight.  Yes, Gustav, that is what my understanding was of the code.  It seemed that wait and join are doing the same thing with no differentiation.  Your explanation of why the 2 commands exist also makes sense.

Thank you all for your time in answering my questions.

[Jim Davidson]

Howdy,

It was my fault the "join" and "wait" both exist (along with "begin" and "create").   The reason is backwards compatibility -- the very first implementation of AolServer threads loosely followed Win32 ("wait" made sense as in WaitForObject or something like that) but quickly shifted to the pthread model as I learned more and came to the conclusion that the pthread model was generally correct in many important and subtle ways and the Win32 model was sadly incomplete and flawed.

-Jim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
aolserver-talk mailing list
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

[Sep Ng]

Thank you for your explanation, Jim!  I appreciate all the input on this.  I have a better understanding on this now.

Regards.

aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk