[omniORB] Stack size problem on DG-UX

[Visscher, Bruce]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>     Hello everyone,
> first of all, apologies for talking about a platform not supported by=20
> omniORB.
> Actually,
> I am looking only for a suggestion  about a possible size=20
> stack problem=20
> of the porting I have.
> My program crash calling huge stack size C functions.
> If I can modify these functions, by decreasing the stack, it=20
> works fine.
>=20
> Could be the stack size for thread as specified in posix.cc=20
> of my porting ?
>=20
> #if defined(__osf1__) && defined(__alpha__) || defined(__VMS)
> // omniORB requires a larger stack size than the default=20
> (21120) on OSF/1
> static size_t stack_size =3D 32768;

At this point, I tend to think that the 32K stack size here was the =
result of bugs in the C run-time library that existed in varying
degrees of severity.  At least, that was the case on the VMS platform, I =
really don't know about the Digital (alias Tru64, alias
OSF/1) Unix.  In fact, 32K was not sufficient for some versions of =
OpenVMS.  But even though it may not needed at this point, I
wouldn't be in favor of removing it.  It's just a default anyway.

> #elif defined(__rtems__)
> static size_t stack_size =3D ThreadStackSize;
> #else
> static size_t stack_size =3D 0;
> #endif

In any case, these values just set the default.  If you have different =
requirements, you can override this by calling
omni_thread::stacksize(int).  Just keep in mind that whatever value you =
supply will be used for every thread you create.  If you
have code that really does use "huge" stack sizes, you might want to =
consider reducing the requirement by allocating on the heap
(via malloc or new).  Note that the main thread likely won't encounter =
any problems, so you could also solve the problem by
utilizing it's stack instead or by using static allocation.  Of course, =
static allocation tends to be thread unsafe.

Bruce

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"

CONFIDENTIALITY NOTE:  This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information.  If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system.  Use, dissemination, distribution, or reproduction of this message and/or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful.


--------------InterScan_NT_MIME_Boundary--