[omniORB] Resizing a string sequence

[Johan Cronje]

On Monday 24 November 2003 23:56, baileyk at schneider.com wrote:
> The oiginal approach appeared OK to me, depending on what the caller does
> with the returned pointer.  Since your method is protected I assumed it was
> not a remote method, e.g. a method defined in an IDL interface.  Gary's
> conclusion that the caller (be it the ORB or otherwise) is going to assume
> ownership and delete the pointer may be the root problem, but your new
> version doesn't solve that since you are deleting the pointer yourself too.
> In addition, both approaches have thread safety issues if this object is
> being shared by multiple threads, as you suggest is the case when you call
> it 'global'.  Perhaps a better approach is
>
> void return_attributes(attribute_list& component_attr)
>   {
>      ...
>      component_attr.length(number_of_attributes);
>      for (int i = 0; i < number_of_attributes; i++){
>         component_attr[i] = CORBA::string_dup(string_obtained_from_fn);
>      }
>      ...
>   }
>
> Or if you want to follow the CORBA convention that a method returning a
> variable length type must allocate on the heap and return a pointer, then
> get rid of your protected member variable altogether and allocate a new
> sequence in each call (e.g. don't delete the old pointer value since it's
> assumed the caller must do that when appropriate).

I forgot to mention that it was only the global variable that was protected,
the method is public. Sorry about that.

In the mean time, I tried the following:

I made component_attr a local variable that I returned (compiler complained 
about this) but it didn't work. 

Then I tried to modify the idl in the following way:

From 
  attribute_list* return_attributes() 
to
  void return_attributes(out attribute_list a_l)

This created some mysterious "attribute_list_out" function that I assume is
a wrapper class as it contains an attribute_list member. For some reason my
idl compiler didn't create attribute_list& as you have above (which is what
I expected). After some time I got to know how this "attribute_list_out"
method works (Can the reason for this class being created be that 
return_attributes may raise exceptions?). Yet I feel I have only plunged
deeper into the abyss, as I can no longer see from gdb backtraces where my
segfaults are coming from (I only know that somewhere along the line it calls
an upcall and ends up in libc6). It is, however, very late over here and I
will continue this conquest at a later stage in the day.

> It would be helpful if you explained what it was you were trying to
> achieve. What is this return_attributes function?  Is it the
> implementation of a CORBA operation?  Do you have a good reason for
> making the component_attr sequence global?
 
Basically, my servant application has 2 functions:
1. Handles all corba comms between my main app and my physical layer blocks
   (I am doing a project on software defined radio).
2. Controls all non-corba functions in the physical layer (when a component
   processes samples, for example).

All components have a text-driven interface for updating their attributes.
This includes listing all attributes as well as modifying component parameters
(for example, an amplifier block's gain).

All references to components are stored in an STL multimap. I did it like this
because a system may have more than one of one type of component, and these 
are distinguished by a unique numerical ID. Thus a component is something like
map<int, components_base_class>.

What return_attributes does is simply return all a specified component's 
attributes, which is of type std::string in my base class (I use string's 
c_str() method to get a c character array).

I thought that making the variable global to make it "returnable" was the
right way to go.

> The CORBA memory management rules are really very simple in this
> respect (not in others). If this is a CORBA function, then it is the
> caller's responsibility to free the returned sequence. It is a memory
> error to do the delete at the start of return_attributes. By the time
> that is reached, the sequence will have already been deleted.

I am very grateful for all the help you give me. I do feel however that at 
this moment I must first go get some rest as I feel that the answer is staring
me in the face but I'm way too tired to see it.

Thanks Again

Best Regards
Johan
-- 
"There is beauty in simplicity"		-- Johan Cronje
---------------------------------------------------------------
Johan Cronje
Digital Signal Processing / Telecommunications Group
Electrical and Electronic Engineering Department
University of Stellenbosch
http://www.dsp.sun.ac.za/~jcronje
---------------------------------------------------------------
GNUPG Key: http://www.dsp.sun.ac.za/~jcronje/jcronje.asc