[omniORB] Thread stack size (again)

[Sai-Lai Lo]

It was a conscious decision to leave array allocation on the stack.

My reasoning was that if the IDL is written so that a huge array is used,
no matter how careful the ORB allocates memory for its upcall arguments,
it isn't difficult for the application code to blow away the stack by defining
an auto variable of the type. Heap allocate an array in your example
actually requires the stub code to either define a dtor for the struct type
or introduce a _var type like storage for the array element so that the
array is cleaned up properly. Not a very elegant solution. Besides, there
is a perfectly appropriate alternative, which is to use sequence in place
of large arrays. So on balance, the decision was to do simple stack
allocation for arrays.

The stack size per thread is an issue. One solution is for the omnithread
library to check for the value of an environment variable,
e.g. OMNITHREAD_STACKSIZE. It uses the value if it is not outrageously
small.

Sai-Lai


>>>>> Bruce Visscher writes:

> Hello omniORBers,
> A user recently came to me with the following problem.  He had an IDL
> that looked something like (but more complicated of course):

> struct x {
>    char x1[100];
> };
> struct y {
>    char y1[100];
> };

> struct z {
>    x xarray[10];
>    y yarray[10];
> };

> struct big {
>    z zarray[23];
> };

> interface i {
>    readonly attribute big mybig;
> };

> He found that the server would crash every time the client invoked the
> accessor method.  He also noticed that if he reduced the size of big
> that the server would no longer crash.  We discovered the problem was in
> the dispatch member of the skeleton class:

>> CORBA::Boolean
>> _sk_i::dispatch(GIOP_S &_0RL_s,const char *_0RL_op,CORBA::Boolean _0RL_response_
>> expected)
>> {
>> if (strcmp(_0RL_op,"_get_mybig") == 0)
>> {
>> if (!_0RL_response_expected) {
>> throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO);
>> }
>> _0RL_s.RequestReceived();
>> big _0RL_result = mybig();

> This is being allocated on the stack from inside of a tcpSocketWorker
> thread.  Inside the omnithread implementation, we have the stack size
> for Compaq (formerly Digital) systems set to 32768 so obviously, this
> isn't going to work.

> The solution in this case was to change the arrays of structs to bounded
> sequences of structs.  After doing this, everything is allocated on the
> heap via new rather than on the stack.

> OTOH, I wonder if it would be good to have the stack size configurable
> either in omnithread and/or omniORB.  Since this issue has come up
> before (some wanting a *smaller* stack size) I wonder if others think
> that this would be a worthwhile modification?




-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND