On 25.05.2019 04:19, Robert Elz wrote:
> Date:Sat, 25 May 2019 02:04:13 +0200
> From:Kamil Rytarowski
> Message-ID: <4fefdf41-44fa-12f9-705d-5187732d7...@gmx.com>
>
>
> | As far as I'm aware we can use read(2) and write(2) in pipes with longer
> | transfers than
On Sat, May 25, 2019 at 02:04:13AM +0200, Kamil Rytarowski wrote:
> As far as I'm aware we can use read(2) and write(2) in pipes with longer
> transfers than 1 byte.
You can't put back data into the pipe for another program to read, so
any kind of read-ahead is impossible in this scenario.
> An
Date:Sat, 25 May 2019 02:04:13 +0200
From:Kamil Rytarowski
Message-ID: <4fefdf41-44fa-12f9-705d-5187732d7...@gmx.com>
| As far as I'm aware we can use read(2) and write(2) in pipes with longer
| transfers than 1 byte.
Of course. But once read we cannot go back
On 24.05.2019 17:09, Michael van Elst wrote:
> On Fri, May 24, 2019 at 10:17:54AM +0200, Kamil Rytarowski wrote:
>
>> Shouldn't that be optimized with libc functions? It calls read(2) for
>> each character.
>
> The input might be read by shell and programs launched by the shell.
> For files you c
On Fri, May 24, 2019 at 10:17:54AM +0200, Kamil Rytarowski wrote:
> Shouldn't that be optimized with libc functions? It calls read(2) for
> each character.
The input might be read by shell and programs launched by the shell.
For files you can read-ahead and seek back, but for pipes you can
only r
On Fri, May 24, 2019 at 10:02:56PM +0700, Robert Elz wrote:
> I wonder what this is doing...
The variable is documented:
"make" variables
Several variables control the behavior of NetBSD builds. Unless
otherwise specified, these variables may be set in either the process
environ
Date:Fri, 24 May 2019 20:29:03 +0700
From:Robert Elz
Message-ID: <27280.1558704...@jinx.noi.kre.to>
And now that I look at this again (unrelated to the issue
of what the trace was showing reading one byte at a time)
I wonder what this is doing...
| if [ -n
Date:Fri, 24 May 2019 13:57:26 +0200
From:Kamil Rytarowski
Message-ID: <049cb255-b647-a241-7d41-4ec2a1151...@gmx.com>
| It prints now program name for the -f option and decodes properly text
| string for read(2).
|
| =2E/truss -o /tmp/log.txt -f /usr/src/buil
On 24.05.2019 11:25, Robert Elz wrote:
> Date:Fri, 24 May 2019 06:34:58 - (UTC)
> From:mlel...@serpens.de (Michael van Elst)
> Message-ID:
>
> | That's probably the shell that must read input byte by byte in most cases.
>
> The shell actually very rarely does o
Date:Fri, 24 May 2019 06:34:58 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| That's probably the shell that must read input byte by byte in most cases.
The shell actually very rarely does one byte reads when not reading
from the terminal (and
On 24.05.2019 08:34, Michael van Elst wrote:
> n...@gmx.com (Kamil Rytarowski) writes:
>
>> Observations:
>> 1. We can observe in both examples that there is a performance issue in
>> build.sh, as something attempts to call 5000 times read(2) for 1 byte onl=
>> y.
>
> That's probably the shell th
11 matches
Mail list logo
