On Tue, 19 Jan 2021 15:34:00 +0000, Pancho wrote:

> On 19/01/2021 15:24, Martin Gregorie wrote:
>> On Tue, 19 Jan 2021 13:46:18 +0000, Pancho wrote:
>>
>>> I think this clarifies in my mind why I wouldn't ever use this
>>> technique to observe events in practice. It is too fragile.
>>
>> So raise a bug to get it fixed: this will help everybody and is, after
>> all, why most Linux distros have decent bug reporting facilities. Plus
>> its quite a good way of thanking the developers for their work.
>>
>>
>>
> There is not a bug, just different implementations, different behaviour.
> Different buffering, different arguments.

Disagree: the delay you're seeing is definitely a bug, though possibly
its a task scheduler issue. If you run less than a buffer-full of data
through a pipe there should not be a noticeable delay under a UNIX/Linux
OS because the buffer is in memory and the task scheduler is a
multitasking scheduler and so can interleave both the writing and reading
tasks without any delay except those caused by task switching and being
preempted by higher priority tasks.

You're reporting multi-second delays you can see which task(s) are
involved: run the delayed pipe again, but this time with 'top' running in
another console window to see what programs are active during the delay.

OTOH Windows 95 pipes always had delays because those worked by:
- the first program created a new temporary file
- wrote the whole dataset to a file
- closed it
- the second program opened the file
- read the whole dataset
- closed the file
- deleted the file

It had to do that because those versions of Windows did not multi-task,
being just a GUI handler sitting on top of MS-DOS 7 and a pipe connecting
more than two programs could be very slow.


--
--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05