On mån, 2007-10-15 at 10:38 -0400, Robert Story wrote: > On Mon, 15 Oct 2007 08:40:45 +0200 Magnus wrote:
> 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. Could you please educate me as to how? I did assume no threads, that insert_filter is a predicate, that insert returns non-zero on duplicate and on error and that remove would remove the key if it was present, so please, as I am curious as to what I have missed. > 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 do not like that either - it do feel kind of blunt. > 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? I think it would be a good idea. Simplification is good. /MF ------------------------------------------------------------------------- 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
