[sr-dev] AVPs in replies?

[Andrei Pelinescu-Onciul]

On Dec 10, 2009 at 12:34, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> On 12/10/09 12:32 PM, Daniel-Constantin Mierla wrote:
> >Hello,
> >
> >Andrei, instead of having K compat mode, as global parameter, I would 
> >prefer to have per transaction function:
> >
> >t_lock_onreply()
> or have t_on_reply(...) accepting a second parameter that indicates the 
> locking status for onreply_route execution.

I see 3 possibilities of fixing it:

1. make parallel avp operation safe using no locks

This would require changes to the way avps are deleted: instead
of immediately unlinking them from the avp list and freeing their memory
they would have to be only marked as deleted. The memory
reclaiming/real delete will happen only when the transaction is
destroyed, or for normal route avps, at the end of the route.

Just to clarify things $a=something involves 2 avp operations:
avp_destroy($a) ; add_new_avp($a, something). So each assignment
involves and avp delete/destroy.
An onreply_route containing something like $avp="foo" will eat memory
for each reply. However this shouldn't really be a problem unless
someone uses really huge avps.

Another disadvantage is that add_avp() will become slightly slower. OTOH
hand this should be offset by the faster destroy_avp.

This change will make the avp safe to use from routes executed in
parallel, however there is no guarantee that they will have the expected
value (it would be like changing unprotected variables from parallel
threads).
E.g.: $a=$a+1 in an onreply route will be undefined if the route is
executed in parallel (e.g. after 2 parallel replies $a could be 1 or 2).
To offset that we could introduce what Daniel proposed
(t_lock_onreply(), t_unlock_onreply()).


2. start with an empty avp list and load the avps and lock the
onreply_route only if certain commands are used (e.g.
t_onreply_load_avps(), t_onreply_unload_avps()) or a global parameter is
set (like k but with the addition of the t_onreply*).

3. based on a config param, either allow only read-only access to avps
 (and no locking) or read-write access (and locking).


Andrei