On Mon, 15 Oct 2007 08:40:45 +0200 Magnus wrote: MF> I think there is a potential resurce leak in CONTAINER_INSERT that MF> require a change to the external interface to fix. MF> MF> Assume a continer with multiple indices. MF> MF> Assume that all index insert functions returns non-zero, then MF> CONTAINER_INSERT returns the same non-zero value as the last index MF> inserter. MF> MF> Now, assume that only the last index insert function returns non-zero, MF> then CONTAINER_INSERT will return the same non-zero value as the last MF> index inserter. MF> MF> How should a developer know if there are any live references to the MF> value left when CONTAINER_INSERT returns non-zero?
They should assume that there are. If they want to be able to safely free the item they were trying to insert, they should call CONTAINER_REMOVE with that item before freeing it. (Which might cause issues with containers that allow duplicates). MF> I believe that the only reasonable definition of 'successful insertion' MF> is that all needed insertions succeded, and thus the code for MF> CONTAINER_INSERT would have to be able to rollback the insertions that MF> already are done in case of trouble. That is not the only reasonable definition. MF> But then the problem is that CONTAINER_INSERT must remember the MF> containers where insertions are done as the result of insert_filter MF> might change as a result of the insertion and k might be in some index MF> even if it wasn't inserted by this run. MF> MF> As a result of those requirements I end up in the following: First of all, the code you provided suffers from exactly the same problem. A failure in later inserts still (potentially) leaves the item in previous containers. There is actually another proposed solution to this issue sitting in the patch tracker. That solution would work - it does a find over all the containers before proceeding with the insert. I'm not keen on that solution either. I think the right way to solve this is actually by creating a new container type - the container container. It would deal with the special case of multiple containers, with much more flexibility and with no penalty to other containers. It could: - have an option for 'all or none' inserts (optimistic) - have an option for 'find before insert' (pessimistic) - have options for callbacks on errors, to allow the user to decide what to do - allow the CONTAINER_* code to be simplified. Thoughts? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
