> I plan to use a simple mutex to avoid the linked list to be > read/written > at the same time. The application won't be under a heavy load so this > isn't a critical point imo. > > Olivier B. >
Oliver, Where do you plan on locking/unlocking the mutex in the subagent code? The obvious place to lock it is in get_first_data_point, but there doesn't seem to be such an obvious place to unlock it. I ask because I am writing some similar code and have been looking into this same issue. Cheers Graeme. Dave Shield wrote : > On 07/12/06, Magnus Fromreide <[EMAIL PROTECTED]> wrote: > >> On ons, 2006-12-06 at 18:41 +0100, Olivier Beytrison wrote: >> > We have small temperature sensors (embedded devices) that will >> > periodically send information through the network to a central server. >> > (those devices can't run their own snmp agent). The application on >> > the server will store the data in a linked list. >> > >> > The same program is a subagent aswell, and will feed the data into >> > the snmp agent of the server. > > > That's the application on the central server, you mean? > Within the same application (same binary) I have : - a TCP Server which acquire the datas from the sensors and feed/update the linked list. (Nothing will be deleted in the list) - a subagent with the code generated from mib2c (iterator_access) which will read the datas within the linked list. The MIB offer only RO values, so there is no settable fields. > > >> > 1. I've choosed the Iterator solution, as explained when running mib2c >> > (the data are held outside from the agent itself). Is that the right >> > choice ? >> >> I'd say no. When you are writing a subagent then the subagent acts as >> agent, so you are holding all data inside the (sub)agent (in that >> linked list) > > > I'm not sure I agree. > Yes - the data is held within the same application binary as the > (sub)agent. > But you could reasonably regard the subagent as a semi-self-contained > unit within the wider application. > > As regards the choice of MIB helper, what's relevant is whether the data > for the table is maintained by SNMP subagent code (i.e. one of the table > data helpers), or "external" to the Net-SNMP-provided code. Exactly, the datas will be maintained externaly from the Net-SNMP-provided code. > If the table data is stored in a linked list, and manipulated by your > main > application code - then this is effectively "external" to the SNMP > sub-unit, > so the iterator is a reasonable choice. > > Otherwise, you're really looking at taking a second copy of the same > data within the application, specifically for the SNMP processing. If > things > change as quickly as you imply, this might not be the best approach. I plan to use a simple mutex to avoid the linked list to be read/written at the same time. The application won't be under a heavy load so this isn't a critical point imo. Thanks for your answers Dave. Olivier B. ----- Olivier Beytrison Student in Telecommunication University of Applied science Fribourg - Switzerland ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
