Re: [Tclhttpd-users] env array pitfalls with threaded tclhttpd

[Brent W. <we...@pa...>]

Tcl goes to great lengths to share the env() array among all threads,
so it is now not that safe to use :-(
We really need to be using, instead, the nsarr stuff, the atomically
shared array-like values that are provided by the latest versions
of the Thread extension.

>>>George Harvey said:
 > Hi,
 > 
 > Following on from my cookie problem last week, I'm now seeing other
 > failures caused by one thread updating the env() array while another
 > thread is using it. In particular, I get an occasional 'no such
 > variable' error while reading an env entry even though the code
 > explicitly checks that it exists before using it. This is most likely
 > because Cgi_SetEnvAll unsets most of the array before re-populating it
 > from the socket data. It isn't just my code that breaks, the env array
 > is also used by some of the standard library modules and I caught one
 > failure when msgcat couldn't read env(LANG).
 > 
 > I can see solutions for some of these issues, for example adding LANG to
 > the 'env-pass' list should prevent it from being unset and I can access
 > the CGI data directly from the socket data, but I was just wondering if
 > there is a more general solution to accessing env() data in a threaded
 > environment.
 > 
 > Regards,
 > George
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
 > Use IT products in your business? Tell us what you think of them. Give us
 > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
more
 > http://productguide.itmanagersjournal.com/guidepromo.tmpl
 > _______________________________________________
 > TclHttpd-users mailing list
 > Tcl...@li...
 > https://lists.sourceforge.net/lists/listinfo/tclhttpd-users
 > 

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
we...@pa...