From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id CA5CF441841 for ; Thu, 26 Mar 2020 21:03:53 +0300 (MSK) Date: Thu, 26 Mar 2020 18:03:52 +0000 From: Nikita Pettik Message-ID: <20200326180352.GD5718@tarantool.org> References: <20200326165413.GD21134@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200326165413.GD21134@atlas> Subject: Re: [Tarantool-patches] [PATCH v2 06/10] box: introduce stacked diagnostic area List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org On 26 Mar 19:54, Konstantin Osipov wrote: > * Nikita Pettik [20/03/25 09:32]: > > + /* > > + * Make sure that adding error won't result in cycles. > > + * Don't bother with sophisticated cycle-detection > > + * algorithms, simple iteration is OK since as a rule > > + * list contains a dozen errors at maximum. > > + */ > > + struct error *tmp = prev; > > + while (tmp != NULL) { > > + if (tmp == e) > > + return -1; > > + tmp = tmp->cause; > > + } > > If you have to do it, better use rlist, rlist_del(e) rlist_add(e), > this will make sure there are no cycles and the cost is constant. rlist implementation is not really suitable for organizing errors into list. See comment in the code: * RLIST implementation is not really suitable here * since it is organized as circular list. In such * a case it is impossible to start an iteration * from any node and finish at the logical end of the * list. > > + if (prev != NULL) { > > + error_unlink_effect(prev); > > + prev->effect = e; > > + error_ref(prev); > > + } > > cause and effect can be just wrappers around rlist_prev/next, if > you have to. But error stack is not always cause and effect: > imagine an SQL update which runs a bunch of triggers which all set > add some errors to the diag, which one of these triggers errors is > the cause of update error?. I guess it is ok to stop execution after first trigger sets an error..? They are fired one by one, not all at once. > > -- > Konstantin Osipov, Moscow, Russia