Hi,
1.10 came with the opportunity of setting the stack size (though still
kind of "application wide") via the static function
Thread::setStackSize call.
I wonder what's the best way for dealing with this function when using
the deployer (that is, without patching RTT/OCL :-)
If I would like to set a particular stack size for each individual
component, I could call the static function in each component's
constructor (side effect: all consequent threads get the same stack
size if I don't do it).
But let's say I want to change the stack size for _all_ threads
created in my application, how do I proceed? AFAIS, if I change the
order of the component instances in my deployer configuration, this
will also change the number of threads that will be created with the
new stack size. So this would force me to create the component that
performs the setStackSize call in its constructor first, ie. always
put it first in the deployer configuration file.
Thoughts, alternatives?
Klaas
[1.10] Setting the stack size using the deployer
On Tuesday 05 January 2010 17:00:48 Klaas Gadeyne wrote:
> Hi,
>
> 1.10 came with the opportunity of setting the stack size (though still
> kind of "application wide") via the static function
> Thread::setStackSize call.
>
> I wonder what's the best way for dealing with this function when using
> the deployer (that is, without patching RTT/OCL :-)
> If I would like to set a particular stack size for each individual
> component, I could call the static function in each component's
> constructor (side effect: all consequent threads get the same stack
> size if I don't do it).
>
> But let's say I want to change the stack size for _all_ threads
> created in my application, how do I proceed? AFAIS, if I change the
> order of the component instances in my deployer configuration, this
> will also change the number of threads that will be created with the
> new stack size. So this would force me to create the component that
> performs the setStackSize call in its constructor first, ie. always
> put it first in the deployer configuration file.
>
> Thoughts, alternatives?
Two options:
1. patch deployer such that it gets a stack size property.
2. load an 'ApplicationSetup' component always first which does these kind of
things.
I recall that we used option 2 quite frequently in applications, with the
knowledge that it had to be always the first component deployed.
Peter
[1.10] Setting the stack size using the deployer
On Wed, 6 Jan 2010, Peter Soetens wrote:
> On Tuesday 05 January 2010 17:00:48 Klaas Gadeyne wrote:
>> Hi,
>>
>> 1.10 came with the opportunity of setting the stack size (though still
>> kind of "application wide") via the static function
>> Thread::setStackSize call.
>>
>> I wonder what's the best way for dealing with this function when using
>> the deployer (that is, without patching RTT/OCL :-)
>> If I would like to set a particular stack size for each individual
>> component, I could call the static function in each component's
>> constructor (side effect: all consequent threads get the same stack
>> size if I don't do it).
>>
>> But let's say I want to change the stack size for _all_ threads
>> created in my application, how do I proceed? AFAIS, if I change the
>> order of the component instances in my deployer configuration, this
>> will also change the number of threads that will be created with the
>> new stack size. So this would force me to create the component that
>> performs the setStackSize call in its constructor first, ie. always
>> put it first in the deployer configuration file.
>>
>> Thoughts, alternatives?
>
> Two options:
>
> 1. patch deployer such that it gets a stack size property.
> 2. load an 'ApplicationSetup' component always first which does these kind of
> things.
>
> I recall that we used option 2 quite frequently in applications, with the
> knowledge that it had to be always the first component deployed.
>
I think the latter option is "The Way To Go"... It is normal to first
deploy your "Containers", before you deploy your application components
into those Containers. With "Container" having the meaning of the
(active, threaded part of the) "middleware" or "run time" part of a framework, such
as in the CORBA Component Model
<http://ccmtools.sourceforge.net/tutorial/node20.html>
<http://www.icmgworld.com/corp/ccm/ccm.contmodel.as
and not with the meaning of an 'encapsulating data structure'
<http://en.wikipedia.org/wiki/Container_%28Type_theory%29>
<http://en.wikipedia.org/wiki/Container_%28data_structure%29>
Herman