[AGENT++] Resource management

[Frank Fock]

Hi Jens,

On 25.10.2010 17:47, Jens Rehsack wrote:
> Hi all,
>
> during development of smart-snmpd prove of concept I encountered
> several resource issues, which I'd like to discuss:
>
> 1) memory management of snmp++/smival
>     I rate it as non-object oriented to derive from smival but implicite delegate
>     memory management to derived classes. This would provoke duplicated
>     code (e.g. in a weak moment I thought about implementing support for
>     float data types as used in ucd-mibs, which would result in many duplicated
>     code of OpaqueStr - because I won't want grant access to the binary
>     bytes of the float)
>     I started a refactoring (see attachment), but to complete it, a
> full rewrite of
>     src/address.cpp will be needed (what might be a good idea anyway ...)
>
This design decision is very old and was made by HP.
We did not want to change it. This is something that might
be done for a 4.0 release of SNMP++.

> 2) fast mutexes
>     agent++ is using fast POSIX mutexes (and doesn't allow to change that
>     easily), but fast mutexes don't stack (same thread locks again and result
>     in some kind of deadlock).

If the same thread does not lock again, there is no problem ;-)
The reason why AGENT++ uses fast mutexes on UNIX is nowadays
no longer valid. More than ten years ago stacking POSIX mutxes
where not consistently working on all major platforms.

Changing the fast mutexes to stacking (PTHREAD_MUTEX_RECURSIVE)
should not be a big problem, as on Windows AGENT++ already uses
recursive locks.

>     Because of mib.cpp can only "update()" MibTable deriveds, it's ugly
>     complicated to manage the updates of our own complex objects.
>     Further, when mutexes don't stack, it's definitively wrong to lock
> the MibEntry
>     on calling get_request()/get_next_request(). Non-stacking mutexes must
>     be controlled by their appropriate owners only.

This point I do not understand. The owner of a mutex is the thread
that create/locks it. Why not locking a MibEntry?
The update method is designed to update the structure of subtree.
Basically it needs to update the last OID in the managed subtree.
Anything else can also be refreshed while in the get_request
method.

>
> 3) MibTable index_info
>     The documentation of index_info is very short and doesn't explain clearly
>     what it's good for (and how it affects is_valid_index).
>     Further: MibTable( oid, int, bool ) constructor's documentation doesn't match
>     it's implementation (what might bring some light into index_info using).
>
The method MibTable( oid, int, bool ) is deprecated. Use the method
with the index_info struct instead.
The purpose of index_info is to specify the length and sub-components
of an index OID:

type = the (base-)syntax of the sub-index object
implied = the length of the sub-index is implied (means no leading 
length sub-id). Can be true only for the last variable length
sub-index.
min = minimum length of the sub-index object measured in 8-bit characters.
max = maximum length of the sub-index object measured in 8-bit characters.
For fixed length sub-index objects like Integer32, min = max.

Best regards,
Frank


-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com