Le 26/09/2010 21:53, Michal Trojnara a écrit :
Pierre DELAAGE wrote:
My patch will lead to have as "default" the /STACK option value of the linker, ie 1MB with wce compiler if /STACK unspecified.
Such a large virtual memory reserved for each stack thread is a very bad idea on 32-bit CPUs. WCE makes it even worse, since each process is contained (unless some special tricks are used) within a 32MB slot: http://msdn.microsoft.com/en-us/library/aa450572.aspx That's why I recently received a report that stunnel is not able to create more than 32 threads on WCE.
Sure, this is where YOUR patch is entering in action, by explicitely specifying a 65K stack for each thread, at _beginthread calling time. This is what I meant by "cumulative" effect of our both patch. Mine is more related to "proper" functionality of _beginthread. With your permission, I will include your gui.c trick on my next patch, so that we have a complete consistent solution to that problem.
It would be uselessly luxuous to modify _beginthread to "really" get the calling thread stack size as default.
I don't remember stunnel using calling stack size for any purpose...
Sure.
In general, after the 4.27 refresh and the unicode bug last year I will stay focused on unicode/ascii support and compilation issues on WCE, and I will deal with "operational" code only when encountering a bug.
I'd appreciate some help with testing as I currently don't have an eVC configured.
This is exactly what I basically offer to the project.
Pierre
stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users