[omniORB] Thread stack size (again)

[Bruce Visscher]

Allan Clark wrote:
> 
> 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.
> 

While I think this would be great if it could be done, I fear this might
be a little complicated to implement.  What I had in mind was something
a little simpler.

As a minium add:

class omni_thread {
  //...
  static int stack_size();
  static void stack_size(int);
};

A value of 0 would mean use the O/S supplied default.  Omni_thread
constructors would then use this value in a call to
pthread_attr_setstacksize or whatever is available for the given O/S.

You could get more elaborate and add an optional argument to the
omni_thread constructors that if set would override the default.  If you
did this then you could have an omniORB parameter for the stack size of
a worker thread (even if you eliminated all "undisciplined" uses of
stack within omniORB, you might still come across a server method that
required a lot of stack space: maybe something heavily recursive).

Just thinking out loud...

Bruce Visscher