Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110329 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99819 invoked from network); 1 Jun 2020 19:23:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jun 2020 19:23:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 36BA6180550 for ; Mon, 1 Jun 2020 11:04:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jun 2020 11:04:47 -0700 (PDT) Received: by mail-ot1-f65.google.com with SMTP id g25so8699230otp.13 for ; Mon, 01 Jun 2020 11:04:47 -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=OJVc4aHIRoC9dL0etw52Vktq0cPQqDDNhG++68cuVsc=; b=GfxhbL9nw+ysDWX+nhHl03BcuUOlta8Vkk3/d1RAGf9aCdkmwcW5S4ATkS0CcWFksG 91/Nz6F11pSOigL0mQKhH7qqZSg3hRExn55/cYEsMRjFJ0q9YT/2dtB+H/cgtgech5aa AxSWMgFX7ET4ch5tpjMcm+M/iBsub9K7sJA+W1twQhcDXXUKubHmNlewFBR/r9pTxlHN zQ8JRZmkCKOuzj13U3jyRtJmsJaBqcQKWI9AlgdR2S9D5se95M3oKE9o2RnImhNPSYev I9TNreqMI2eyGvQSf1QS/V3pnO81VF5XpmPZgzBdpI3cpE5Yb2xTcRJ++FAj1O2KvFz7 gRhA== 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=OJVc4aHIRoC9dL0etw52Vktq0cPQqDDNhG++68cuVsc=; b=Zpr68mo0nVkB7fxVTMEg+UPLY3xvyLqq9PsxKLOSSpXDxuTkpXOJv2oXpenH5aKfxp 7UXPYlyAV7/r2UMe7DLyB8EuUhzGKDxFHmE5WPY1OBJEeocJMeqeNIedFY/h/slO+uAG NUphYkAZmBbaTuInlAGIpR3rTsQJqR6RlAEDI/omFc22BEkFenfuXJDpu79btXwi4eG0 hdal8O7TB47Izz2zMVGxJxM1Oka1oV/lPT8ap61VT1Qr2kZ76ZH3yYREv3AvmPJXqgZl IkLYd4+Sn0aNlWRURhNpWTvfAPD8DFSmlEwC5oBFzQhtXOeUm1zizxL/LtFqXM7MYm/a dRUg== X-Gm-Message-State: AOAM5335oS/uLXzzjvMHMi/wH4wqTrSGDJP1JZMhTr1gvRpRZU9IoyGK NWFMy+IM3Aq06X0IJ+xc/pRdSg4PuJW27BTGktybOA== X-Google-Smtp-Source: ABdhPJxjmoo+vl2D9gwEqaf8yHQUNTceelBxLl5x8je27uZ4m/E95QsyUdeBRcK1xZOhHV1f9kK5YZEz8XjzLPbRGLg= X-Received: by 2002:a9d:27a3:: with SMTP id c32mr18615723otb.233.1591034687033; Mon, 01 Jun 2020 11:04:47 -0700 (PDT) MIME-Version: 1.0 References: <9653428e-643a-cfb1-4966-c1f32db2ab0e@birkholz.biz> In-Reply-To: Date: Mon, 1 Jun 2020 19:04:32 +0100 Message-ID: To: Dennis Birkholz Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000058971605a709a18a" Subject: Re: [PHP-DEV] RFC proposal: fsync support for file resources From: davidgebler@gmail.com (David Gebler) --00000000000058971605a709a18a Content-Type: text/plain; charset="UTF-8" Just to add and clarify; operating systems have their own internal write buffers. When you call fflush() you are saying "immediately flush this data from my program buffers to the operating system". When you call fsync() you are saying "immediately flush this data from my program buffers to the operating system *and tell the operating system to immediately flush its buffer to disk too*", so when this function returns success status you can be as reliably sure as possible that data has been physically persisted. fflush does not provide this assurance. On Mon, 1 Jun 2020, 18:52 David Gebler, wrote: > No, fflush will flush the PHP application buffers out to the operating > system, it does in contrast to fsync not provide a guarantee the operating > system will immediately persist to the underlying storage device. > > On Mon, 1 Jun 2020, 18:49 Dennis Birkholz, > wrote: > >> Hello David, >> >> isn't fflush exactly this: >> https://www.php.net/manual/en/function.fflush.php >> >> Greets >> Dennis >> >> Am 01.06.20 um 18:56 schrieb David Gebler: >> > Exactly as the subject says, I would like to propose an RFC for adding >> an >> > fsync() function for file resources, which would in essence be a thin >> > wrapper around C's fsync on UNIX systems and _commit on Windows. >> > >> > It seems to me an odd oversight that this has never been implemented in >> PHP >> > and means PHP has no way to perform durable file write operations, >> making >> > it inherently unsuitable for any systems requiring more intensive I/O, >> > mission critical logs, auditing, etc. >> > >> > I am not really a C programmer and I have been able to implement a >> simple >> > working prototype of this as a compiled extension in merely a few >> hours, so >> > I'm sure it wouldn't be difficult to bring in to the language core where >> > the functionality really belongs. >> > >> > Every other major programming language otherwise comparable to PHP in >> > features supports a way of providing durability. >> > >> > Thanks. >> > >> >> --00000000000058971605a709a18a--