From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 04CE844BEA for ; Wed, 9 Nov 2022 09:31:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D42A568BA98; Wed, 9 Nov 2022 11:31:23 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EA1C968BA36 for ; Wed, 9 Nov 2022 11:31:16 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 8801D2404F7 for ; Wed, 9 Nov 2022 10:31:16 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GZQlFLxz_P3l for ; Wed, 9 Nov 2022 10:31:15 +0100 (CET) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id E4B14240499 for ; Wed, 9 Nov 2022 10:31:15 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id D1D041601B2; Wed, 9 Nov 2022 10:31:15 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20221108112550.8375-1-anton@khirnov.net> <20221108112550.8375-3-anton@khirnov.net> <166791645128.20155.3271115273476016820@lain.khirnov.net> <166792556582.1198.13952919773053108092@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 09 Nov 2022 10:31:15 +0100 Message-ID: <166798627583.1198.13595963875436534964@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN) X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Nicolas George (2022-11-09 09:21:34) > Anton Khirnov (12022-11-08): > > Sure, and that's about it. And as I said before - there is no way to > > tell when a device will be ready, so this is of very limited usefulness. > > This is not true for many devices. Sorry to contradict you once again, > but you would know it if you had any experience working with devices. We could really do with fewer of these personal attacks. > > That is not a meaningful difference. A meaningful difference would be > > one that has actionable consequences. > > Well, it has actionable consequences: if you treat EAGAIN like REDO you > introduce a busy wait, In most devices it's a sleep rather than a busy wait. And in those where it isn't, it should be. Furthermore, since the caller has no way of knowing how long to wait, there is little they can do other than sleeping for a random period and hoping for the best. > and if you treat REDO like EAGAIN you introduce a > significant slowness. Now that you make me mention it, I remember it was > precisely the reason I introduced REDO: to fix a slowness in resyncs. I highly doubt that returning control back to the caller will cause any slowdown in and of itself, it's more about what the caller will do in response. If they choose to sleep for a random amount of time, then maybe they should stop doing that (which is exactly what this patchset does). -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".