Re: [AOLSERVER] 3.3+ad13 w/ Tcl 8.4.1 ?

[Jim Davidson]

In a message dated 1/6/03 8:59:58 PM, [EMAIL PROTECTED] writes:

On Mon, Jan 06, 2003 at 01:54:05PM -0800, Jeff Hobbs wrote:
> > Has anyone successfully built and used Tcl 8.4.1 (or any flavor of 8.4
> > for that matter) with AOLserver 3.3+ad13, or a similar AOLserver
> > version (aka, pre-3.5)?  If you have, could you tell me how you built
> > it?

> I don't have that version of AOLServer to compare against, but Tcl 8.4.1
> should not require any core patching to work with AOLServer now.  I'm
> not sure if that also accompanied changes to AOLServer code ...

Yes, that's what I don't know either, whether Tcl 8.4.1 can be used
stock with ALL versions of AOLserver, or whether AOLserver was changed
c. versions 3.5 and 4.0 to be able to use the stock Tcl.  Who knows
for sure?

I did try to hack up Tcl 8.4.1 the way 8.3.2 was hacked for AOLserver
3.3 (+ad13, although I doubt that matters in this context).  I failed
miserably.  For your amusement, I've attached my README.AOLSERVER with
all my notes on what I did on how it broke.

On the other hand a completley stock 8.4.1 w/ 3.3+ad13 DID build
libtcl8.4g.a and nsd8x successfully, but a brief test showed that it
DEFINITELY wasn't working right - crashing with bus errors, bad stuff
like that.

Back in July, Roberto Mello reported that his AOLserver 3.3+ad13 w/
Tcl 8.4b1 crashed several times while testing, but I don't know how he
built it.

I'll probably try AOLserver 3.5 next, but it would be nice to know if
and how older versions of AOLserver can be made to work with Tcl 8.4.

--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com

Hi,

If I recall correctly, the mods to Tcl 8.3.2 for AOLserver 3.x were in a few areas:

- Fixes to a memory leak or two and use of thread safe functions (e.g., ns_readdir instead of readdir).  Tcl 8.4 should have all these fixes now.

- Setting default channel encoding to binary just for backwards compatibility with old Tcl code. I think we gave up on this in 3.5 and 4.0 after fixing most places it was a problem (e.g., the ns_form code for multipart forms).  I'd suggest ignoring that previous hack.

- Use of nsthreads instead of Tcl Win32 or pthread code for better platform independence. AOLserver could be compiled against non-pthread Unix thread libraries in the past (e.g., SGI multiprocessing API's) but now requires pthreads so it should be fine to leave the Tcl thread code as is.

- Redirection of Tcl's memory allocation to AOLserver's fast thread allocator and custom Tcl_Obj allocator which was necessary because standard Tcl code would lock up under moderate load here at AOL.  Tcl 8.4 now includes AOLserver's fast allocator in the core.

So, if you build Tcl 8.4 just like you would for AOLserver 3.x, specifically with the --enable-threads, and then do minimal hacks to AOLserver makefiles things should compile find.  I think that's what you did but running it resulted in crashes.  I'm guessing the crashes were related to the last point above.  The reason is that linking old AOLserver code in this manner would have Tcl and AOLserver using different memory allocators and sometimes they get mixed up (e.g., an ns_malloc later Tcl_Free'd or free'd) - there's an example of this mixup in the old nsperm code.  To fix this, you could try one or both of the following:

1.  Modify nsthreads to use Tcl_Alloc, Tcl_Free.  This is how AOLserver 3.5 and 4.0 work.  It adds a dependency on Tcl for nsthreads but that shouldn't be hard to work around.  In fact, you may be able to use the nsthread library for 3.5 directly.  This would fix mixing ns_malloc with Tcl_Alloc but would not fix mixing with malloc/free.

2.  Disable the fast allocator on AOLserver (which was the default mode if nsd was started without the -z flag) and then disable the fast allocator when building Tcl 8.4 with -DUSE_THREAD_ALLOC=0.  This would direct Tcl_Alloc and ns_malloc to normal malloc.  If you then find performance a problem, you could consider pre-loading some faster malloc replacement (e.g., www.hoard.org).

If that doesn't fix the crash, send a stack trace - it might remind me of some other Tcl/AOLserver weirdness from long ago :)

-Jim