[omniORB] Thread stack size (again)

[Allan Clark]

Bruce Visscher wrote:

> 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):
>
> [ ... ]
>
> 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:
>
> [ ... ]
>
> 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.

OUCH!

Default stack size within SCO UnixWare is 16k per thread (if memory serves).

> 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.

Perhaps instead the tcpSocketWorker should use some dynamic memory for this, allocate
explicitly on the heap.

> 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?

I do, for one.  I have not pushed through the omniorb code much, but I was working
with a previous (commercial) ORB vendor.  A major problem in their code was the
undisciplined use of stack space, blowing my tiny stack sizes out of the water.

Can we conditionally-compile on a "go/no-go" decision, where the code is compiled to
go with stack/heap based on the result of:

#define STACK_THRESHOLD 256

#if (STACK_THRESHOLD < SIZEOF_somebuffer)
#define USESTACK_somebuffer 1
#else
#define USESTACK_somebuffer 0
#endif

.. and later in code ...

#if (0 == USESTACK_somebuffer)
struct somebuffer _actual_buf;
struct somebuffer *buf = &_actual_buf;
#else
struct somebuffer *buf;

buf = (somebuffer *) malloc (sizeof (struct somebuffer));
#endif

.. OK, it's scarey, would take a lot of pushing through the code, and perhaps it's a
bad solution.  I only post it as a solution to building code which can be compiled
with a configurable "limit" on the size of stack-based items, automatically creating
heap items as this threshold is reduced.  This would allow a -Dxxx compiler directive
make the decision between size or performance.

My comment on default thread constructors still holds.

Allan