[stunnel-users] Critical error on stunnel 434 for WinCE/Windows Mobile: no service at all, because of failure in thread creation

Pierre DELAAGE delaage.pierre at free.fr
Sun Sep 26 23:07:13 CEST 2010


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 at mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users




More information about the stunnel-users mailing list