On 06.06.2020 at 01:39, David Gebler wrote:
> Thanks, my browser was automatically populating the wrong email, I've now
> registered. Apparently I need to request karma now? Username dwgebler.
RFC karma granted.
I'm not sure whether this feature needs an RFC, though. Maybe just
start with a pul
Thanks, my browser was automatically populating the wrong email, I've now
registered. Apparently I need to request karma now? Username dwgebler.
On Sat, Jun 6, 2020 at 12:19 AM Christoph M. Becker
wrote:
> On 06.06.2020 at 00:00, David Gebler wrote:
>
> > As a side-note, I am unable to register
On 06.06.2020 at 00:00, David Gebler wrote:
> As a side-note, I am unable to register a wiki.php.net account to raise
> this RFC, I get a very unhelpful error message which just says "That wasn't
> the answer we were expecting" when I submit my details. Anyone have any
> idea what that is?
I assu
As a side-note, I am unable to register a wiki.php.net account to raise
this RFC, I get a very unhelpful error message which just says "That wasn't
the answer we were expecting" when I submit my details. Anyone have any
idea what that is?
On Thu, Jun 4, 2020 at 3:19 PM David Gebler wrote:
> It's
It's interesting that you mention fdatasync - perhaps a better C programmer
than I am can correct me, but I don't think it has an equivalent on
Windows, where _commit() is a wrap on FlushFileBuffers API. So in respect
of PHP implementation, the options would be:
fdatasync() is not available on Win
On Mon, Jun 1, 2020 at 6:57 PM David Gebler wrote:
> 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 overs
fsync() does not *guarantee* data has been persisted because no software
mechanism which exists can do that. It is however the *best assurance* we
can have that data has been physically persisted by the time the function
returns.
fsync() is the best operating-system level assurance we can get rega
Am 01.06.2020 um 18:56 schrieb David Gebler :
> 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, a
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 op
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 ex
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
>
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
12 matches
Mail list logo
