From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 149F4C4363A for ; Thu, 22 Oct 2020 09:09:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B32532245F for ; Thu, 22 Oct 2020 09:09:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dwDoya2F" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2507654AbgJVJJ4 (ORCPT ); Thu, 22 Oct 2020 05:09:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2502677AbgJVJJz (ORCPT ); Thu, 22 Oct 2020 05:09:55 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED1BAC0613CE for ; Thu, 22 Oct 2020 02:09:54 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id e17so1231038wru.12 for ; Thu, 22 Oct 2020 02:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P0YthKFoZ4j0kiGVsFb+dn8gBfNOjZoUlaQ9/YAhgm0=; b=dwDoya2F0mES2OgtaLRH4mW9V0svWT/dBiwKzclNQ9Mw6sY97JdjhzyGishZ3ZXV6R GD9OW5Ypwf2JMoihPIEzbWtXnXXtIBI0gYlpGpkMQlgYCaVamfYOjzJHZUnrlNcpku63 bq+rYKycMBeb0SY1JxUuSe3afS1FspwBUMNa5YKgFHl4quC+taCtOiykBpV6LeduUO62 wtP9PoR1lzsyXKwTStjDJsSawLsErKP9xoswXnqBRej46j/UHMhQ45BiCfC+0b9hb4/f JtQY7gIJ+xwfZwMnPB8DcOJ+UgkqjZPf6Sm7mgai8NmoK5CZGEPJY2PTu92ZFnJapXJz 6XgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P0YthKFoZ4j0kiGVsFb+dn8gBfNOjZoUlaQ9/YAhgm0=; b=N5MpBFg+qpHAPhq3NmQZcorSILya7L7j2Bs2CrD73d/JgLFJNQRcEGbbvaknV63wQV hE7G6hgQgQJzuKCZ79MyX63/t5Drw6xGWdz8wvu2Dp0adh3dAcS11ayV/8/uzRQB/pgR KLQz6zmID8ywJi1WKGfLTlN7fkAJfw9+rjj+XXTC3ZIVxRDMoUPMt3b9WKidWV8K+pzV ouWlGySzZPVb1GE+UFSzjGzxHP0918XGflpGppCQUXH6vvKFjTxzAL7gAqmyzMIIQTjP KqOMNbcTsAnMhhdDEplsLIXzRfiUONn+loGgjbnqT+XY0+zP1JsSSQK5QcAx6i+qgD2z 2SPw== X-Gm-Message-State: AOAM532BdUMnxXqyc7IL3P9fPvaKovE03nDw3BBrrmqhEGIQ/DYlDV6E 4WFg78wSS9h8pAeDSHcMxXml+d2KK1JQ6YQaWVnjhqsSclQ= X-Google-Smtp-Source: ABdhPJy3LSYh6IFtdCdye+G51LeAHs6ZJbOLr+CYYHFCTvQX+O1wGtkgtnTLAX8sC8Qbga8ZClwuRG6GbJT4sOjaVsE= X-Received: by 2002:adf:9069:: with SMTP id h96mr1706021wrh.358.1603357793413; Thu, 22 Oct 2020 02:09:53 -0700 (PDT) MIME-Version: 1.0 References: <20201015083805.GA10354@laureti-dev> <20201015093526.GA10891@laureti-dev> <20201015105718.GA11027@laureti-dev> <20201015121312.GA7166@laureti-dev> <20201022063935.GA23978@laureti-dev> In-Reply-To: <20201022063935.GA23978@laureti-dev> From: Jack Winch Date: Thu, 22 Oct 2020 12:09:42 +0300 Message-ID: Subject: Re: [libgpiod] cxx bindings: time_point vs duration To: Helmut Grohne Cc: Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org > You're arguing that a std::chrono::steady_clock::time_point is not a good match due to its undefined ratio. std::chrono::steady_clock::time_point is not a good match for the reasons you have quoted. > That can be fixed by using a clock with a well-defined ratio. I agree that defining a clock with a suitable ratio would remove the problems faced when using a clock with an undefined ratio. > The key here is that while you can easily convert your duration to a > time_point, a duration is conceptually the wrong thing to use. I agree that the timestamp value is conceptually a time_point. > If you are not satisfied with the resolution > guarantuee of steady_clock, just make your own clock. Doing so results > in a lot of type safety. For instance, if you accidentally compute a > difference between a system_clock::time_point and a gpiod timestamp, > using a duration would just work whereas a time_point would result in a > compilation failure. I also agree with the excellent point you raise regarding type safety and preferring compile-time errors to runtime errors. Where possible, care should be taken to mitigate or eradicate the potential for these types of runtime bug. The problem is, the solution you were suggesting to be suitable was not (in its current form). There are numerous issues with the proposal above, which require further discussion. As has been pointed out, changes were made to the char dev in Linux 5.7 such that line events are timestamped using the system 'monotonic' clock as opposed to the 'realtime' clock. So now the clock in which that timestamp is relative to is kernel version dependent. The ability to configure this will become available in the next version of the kernel, but the problem of which system clock is being used for older kernels will still remain. I rebuffed the suggestion in the manner that I did as the change would have caused issues. I completely understand and agree with the key rationale behind the proposed change. With further discussion, a suitable solution might be found, but it requires further thought. What I did not want to see happen is the change as currently proposed be applied and cause issues in the future. That being said, let's continue this discussion to see what can be done (and preferably without any p*ssing contest). The remainder of this week is no good for me, but would you be available to discuss potential solutions next week, Helmut? Jack