[omniORB] Thread stack size (again)

[jon.kristensen@kongsberg-simrad.com]

I am also working on an embedded platform, and the name argument would have been
useful to me as well.
I think it should be considered for the next release (3.0).

Btw, the name argument is of little use unless the ORB implementation uses it.

-------
Jon Kristensen
Kongsberg Simrad AS, Horten Norway
phone:    +47 33 03 43 62
fax: +47 33 04 76 19
email:    jon.kristensen@kongsberg-simrad.com





David Byron <dbyron@coactive.com> on 23.09.99 20:44:56
To:   Sai-Lai Lo <S.Lo@uk.research.att.com>, Bruce Visscher <visschb@rjrt.com>
cc:   omniorb-list@uk.research.att.com (bcc: Jon Kristensen/NOHRT/KS/KM/KOG)
Subject:  Re: [omniORB] Thread stack size (again)




At 07:09 PM 9/23/99 +0100, Sai-Lai Lo wrote:
> >>>>> Bruce Visscher writes:
>
> > 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.
>
>This seems reasonable. Only drawback is we are changing the interface.
>I think we are alright with unices shared libraries. Windows are OK as well
>I guess because the omnithread DLL is built to resolve by name. Otherwise,
>we have to bump up the library version number.

What we've done here on our embedded platform is to change the signature of the
omni_thread constructors (and the create functions and common_constructor) to
add these arguments:

                 unsigned int stk_size = 0,
                 const char *name = NULL );

They're all defaulted so the code in the orb didn't need to change as a result.
We did have to recompile though.  The name field is really just a debugging aid
since the real-time O/Ss we use support it.

We also added more granularity to the priorities to give us the flexibility we
need to write our application.

-DB
---
David Byron                     dbyron@coactive.com
Coactive Networks, Inc.         http://www.coactive.com
4000 Bridgeway, Suite 303       voice:(415)289-1722
Sausalito, CA  94965            fax:(415)289-1320