Tasking, AWS and segmentation faults

Tasking, AWS and segmentation faults

[tonyg]

I have a function which is an aws response. In that function I have an array of 86400 records which are processed. I was sort of expecting an error and I got one which is 

Exception name: STORAGE_ERROR
Message: s-intman.adb:139 explicit raise

I think I need to reserve some space using the storage pragma but I am wondering if anyone experienced in using AWS  have any advice 

Re: Tasking, AWS and segmentation faults

[Vadim Godunko]

On Apr 4, 8:08 pm, tonyg <tonytheg...@gmail.com> wrote:
> I have a function which is an aws response. In that function I have an array of 86400 records which are processed. I was sort of expecting an error and I got one which is
>
> Exception name: STORAGE_ERROR
> Message: s-intman.adb:139 explicit raise
>
> I think I need to reserve some space using the storage pragma but I am wondering if anyone experienced in using AWS  have any advice

I guess that you allocate this array on stack, isn't it? You need to
allocate it using 'new' and deallocate it after use by instantiation
of Ada.Unchecked_Deallocation.

Re: Tasking, AWS and segmentation faults

[Georg Bauhaus]

On 04.04.12 18:08, tonyg wrote:
>
> I have a function which is an aws response. In that function I have an array of 86400 records which are processed. I was sort of expecting an error and I got one which is
>
> Exception name: STORAGE_ERROR
> Message: s-intman.adb:139 explicit raise
>
> I think I need to reserve some space using the storage pragma but I am wondering if anyone experienced in using AWS  have any advice


If the function "causing" the storage error is in the environment
task (main unit), you could allocate more stack space to it.
On Unix, the shell's ulimit allows adjusting the amount of stack
space available programs.
If the function is defined in some Ada task, placing pragma Storage_Size
in the task type's declaration will do the trick.
If neither solution is satisfactory, you could resort to
pointers and manual memory management; see Vadim Godunko's response.

Re: Tasking, AWS and segmentation faults

[Jeffrey Carter]

> On 04.04.12 18:08, tonyg wrote:
>>
>> I have a function which is an aws response. In that function I have an array
>> of 86400 records which are processed. I was sort of expecting an error and I
>> got one which is
>>
>> Exception name: STORAGE_ERROR
>> Message: s-intman.adb:139 explicit raise

Since this is an AWS response function, it's called from an AWS "slot" task. I 
don't know any way to set the stack size for these tasks, so you'll either have 
to use a different data structure [an unbounded array ("vector") would do, since 
it moves your data into the heap] or explicitly move your array into the heap.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Tasking, AWS and segmentation faults

[tonyg]

Thanks for your help guys its working lovely now and I know something new! 

What I did was (after reading the advice here) was I used a pointer and declared a 'new type' and then passed that pointer around.

Re: Tasking, AWS and segmentation faults

[Georg Bauhaus]

On 05.04.12 12:38, tonyg wrote:
> Thanks for your help guys its working lovely now and I know something new! 
> 
> What I did was (after reading the advice here) was I used a pointer and declared a 'new type' and then passed that pointer around.

For the sake of completeness, and without knowing what
you are actually doing, so I could be quite wrong, you
can still pass Pointer.all around (or rename this and
pass it around as before).
Large arrays are typically passed around by reference.
Dereferencing keeps the impact of using pointers local,
and easy to change again, just in case.

Re: Tasking, AWS and segmentation faults

[tonyg]

On Thursday, 5 April 2012 12:03:55 UTC+1, Georg Bauhaus  wrote:
> On 05.04.12 12:38, tonyg wrote:
> > Thanks for your help guys its working lovely now and I know something new! 
> > 
> > What I did was (after reading the advice here) was I used a pointer and declared a 'new type' and then passed that pointer around.
> 
> For the sake of completeness, and without knowing what
> you are actually doing, so I could be quite wrong, you
> can still pass Pointer.all around (or rename this and
> pass it around as before).
> Large arrays are typically passed around by reference.
> Dereferencing keeps the impact of using pointers local,
> and easy to change again, just in case.

ooh ooh I forgot to dereference it! jeepers. Thanks for that you have just extended the life of my webserver beyond a fwe requests!

Re: Tasking, AWS and segmentation faults

[Simon Wright]

tonyg <tonythegair@gmail.com> writes:

> On Thursday, 5 April 2012 12:03:55 UTC+1, Georg Bauhaus  wrote:
>> On 05.04.12 12:38, tonyg wrote:
>> > Thanks for your help guys its working lovely now and I know
>> > something new!
>> > 
>> > What I did was (after reading the advice here) was I used a pointer
>> > and declared a 'new type' and then passed that pointer around.
>> 
>> For the sake of completeness, and without knowing what
>> you are actually doing, so I could be quite wrong, you
>> can still pass Pointer.all around (or rename this and
>> pass it around as before).
>> Large arrays are typically passed around by reference.
>> Dereferencing keeps the impact of using pointers local,
>> and easy to change again, just in case.
>
> ooh ooh I forgot to dereference it! jeepers. Thanks for that you have
> just extended the life of my webserver beyond a fwe requests!

I think you mean deallocation; and yes, indeed you should!

What Georg meant was that your called subprograms could still take array
parameters:

   type Arr is array (Natural range <>) of Thing;

   procedure Sub (A : in out Arr);

   type Arr_P is access Arr;

   Actual : Arr_P := new Arr (0 .. 65535);

   Sub (A => Actual.all);

Re: Tasking, AWS and segmentation faults

[J-P. Rosen]

Le 05/04/2012 18:22, Simon Wright a �crit :
> What Georg meant was that your called subprograms could still take array
> parameters:
> 
>    type Arr is array (Natural range <>) of Thing;
> 
>    procedure Sub (A : in out Arr);
> 
>    type Arr_P is access Arr;
> 
>    Actual : Arr_P := new Arr (0 .. 65535);
> 
>    Sub (A => Actual.all);

or even better:
    Actual_P : Arr_P := new Arr (0 .. 65535);
    Actual : Arr renames Actual_P.all;

   Sub (A => Actual);

and forget totally about pointers!
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Tasking, AWS and segmentation faults

[Pascal Obry]

Jeffrey,

> Since this is an AWS response function, it's called from an AWS "slot"
> task. I don't know any way to set the stack size for these tasks,

You can use the Stack_Size parameter of the Start procedure or configure
the size in an AWS.Config.Object or set this value into aws.ini or
application_name.ini, no I don't think there is another way :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Tasking, AWS and segmentation faults

[Jeffrey Carter]

On 04/05/2012 09:58 AM, Pascal Obry wrote:
>
>> Since this is an AWS response function, it's called from an AWS "slot"
>> task. I don't know any way to set the stack size for these tasks,
>
> You can use the Stack_Size parameter of the Start procedure or configure
> the size in an AWS.Config.Object or set this value into aws.ini or
> application_name.ini, no I don't think there is another way :)

Good. I forgot to look at the parameters of Start. I did look in AWS.Config.Set 
and didn't see anything there.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: Tasking, AWS and segmentation faults

[Pascal Obry]

Jeffrey,

> Good. I forgot to look at the parameters of Start. I did look in
> AWS.Config.Set and didn't see anything there.

There is a procedure named Line_Stack_Size in AWS.Config.Set.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Tasking, AWS and segmentation faults

[Jeffrey Carter]

On 04/05/2012 10:18 AM, Pascal Obry wrote:
>
> There is a procedure named Line_Stack_Size in AWS.Config.Set.

Right. I wasn't clear what that set.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: Tasking, AWS and segmentation faults

[tonyg]

On Thursday, 5 April 2012 19:30:36 UTC+1, Jeffrey Carter  wrote:
> On 04/05/2012 10:18 AM, Pascal Obry wrote:
> >
> > There is a procedure named Line_Stack_Size in AWS.Config.Set.
> 
> Right. I wasn't clear what that set.
> 
> -- 
> Jeff Carter
> "To Err is human, to really screw up, you need C++!"
> Stéphane Richard
> 63

I think Pascal has the way I should be using. Though the pointer thing worked well too.
 Some else at a linux user group meeting pointed out very reasnably that my code to use 86400 records was probably a little dubious and I'm taking another look at this. Thing was processing speeds are so high now that this makes me lazy!