| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:25:16 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,522 |
| Posted today: | 6 |
On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
Pipes are good.
But, really, they're just temp files the parent
process can access.
Pipes *could* be implemented with temporary disk files, at least to an extent, but as far as I can tell, they're not.
Whatever M$ does ... well ....... always seems
to be FUCKED somehow.
On Sat, 16 Nov 2024 00:37:35 -0500, 186282@ud0s4.net wrote:
IF you are doing multi-threaded/process style pgms then you almost
HAVE to use them if you want to xmit more than a few bytes between
parents/children. A few years back I was experimenting with TCP/UDP
servers and found that it could be very useful to transmit a few
dozen bytes worth of active data between parents/children.
SO ... learn yer pipes !
Message queues and shared memory are handy for IPC too. I don't think Microsoft ever figured either out. What they call message queues are completely different.
Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes:
On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
Pipes are good.
But, really, they're just temp files the parent
process can access.
Pipes *could* be implemented with temporary disk files, at least to an
extent, but as far as I can tell, they're not.
“Temporary files the parent can access” is not a good model for a couple of reasons:
* The semantics are different. Bytes read from a regular file are still
there to be read again if you rewind the file; bytes read from a pipe
are gone. Empty/full files behave differently to empty/full pipes.
* Temporary regular files can already be accessed by other processes by
name, by file descriptor inheritance, or file descriptor passing.
On 2024-11-16, 186282@ud0s4.net <186283@ud0s4.net> wrote:
Whatever M$ does ... well ....... always seems
to be FUCKED somehow.
"The day Microsoft makes a product that doesn't suck
is the day they make vacuum cleaners."
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
“Temporary files the parent can access” is not a good model for a
couple of reasons:
* The semantics are different. Bytes read from a regular file are still
there to be read again if you rewind the file; bytes read from a
pipe are gone. Empty/full files behave differently to empty/full
pipes.
* Temporary regular files can already be accessed by other processes by
name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR, just that they
CAN do most of the stuff pipes are used for and in an easier user/code-friendly fashion.
SIZE is almost unlimited too.
On Sat, 16 Nov 2024 23:59:41 -0500, 186282@ud0s4.net wrote:
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
“Temporary files the parent can access” is not a good model for a
couple of reasons:
* The semantics are different. Bytes read from a regular file are still
there to be read again if you rewind the file; bytes read from a
pipe are gone. Empty/full files behave differently to empty/full
pipes.
* Temporary regular files can already be accessed by other processes by
name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR, just that they
CAN do most of the stuff pipes are used for and in an easier
user/code-friendly fashion.
Not really, no.
SIZE is almost unlimited too.
That is another reason they don’t work.
On 11/17/24 12:30 AM, Lawrence D'Oliveiro wrote:
On Sat, 16 Nov 2024 23:59:41 -0500, 186282@ud0s4.net wrote:
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
“Temporary files the parent can access” is not a good model for a
couple of reasons:
* The semantics are different. Bytes read from a regular file are
still there to be read again if you rewind the file; bytes read
from a pipe are gone. Empty/full files behave differently to
empty/full pipes.
* Temporary regular files can already be accessed by other processes
by name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR, just that they
CAN do most of the stuff pipes are used for and in an easier
user/code-friendly fashion.
Not really, no.
SIZE is almost unlimited too.
That is another reason they don’t work.
It's a block of info, just by one means over another.
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes:
But, really, they're just temp files the parent process can access.
Pipes *could* be implemented with temporary disk files, at least to an
extent, but as far as I can tell, they're not.
“Temporary files the parent can access” is not a good model for a
couple of reasons:
* The semantics are different. Bytes read from a regular file are
still there to be read again if you rewind the file; bytes read from
a pipe are gone. Empty/full files behave differently to empty/full
pipes.
* Temporary regular files can already be accessed by other processes
by name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR,
just that they CAN do most of the stuff pipes are used for and in an
easier user/code-friendly fashion.
SIZE is almost unlimited too.
Anyway, I'd made some TCP/UDP servers but the parent needed
to know the status of the children in a little more detail
than just a tiny return code - might want to terminate the
child if it'd been idle for awhile, might want to know how
much bandwidth was being used, might want to pick a good
time to do some maint routines, might want to know WHO the
connections were from. Pipes were the (relatively) easy
'C'-approved method and did the job very well.
On Sun, 17 Nov 2024 01:05:20 -0500, 186282@ud0s4.net wrote:
On 11/17/24 12:30 AM, Lawrence D'Oliveiro wrote:
On Sat, 16 Nov 2024 23:59:41 -0500, 186282@ud0s4.net wrote:
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
“Temporary files the parent can access” is not a good model for a >>>>> couple of reasons:
* The semantics are different. Bytes read from a regular file are
still there to be read again if you rewind the file; bytes read
from a pipe are gone. Empty/full files behave differently to
empty/full pipes.
* Temporary regular files can already be accessed by other processes >>>>> by name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR, just that they
CAN do most of the stuff pipes are used for and in an easier
user/code-friendly fashion.
Not really, no.
SIZE is almost unlimited too.
That is another reason they don’t work.
It's a block of info, just by one means over another.
You’re forgetting the sequencing and synchronization aspects.
"186282@ud0s4.net" <186283@ud0s4.net> writes:
On 11/16/24 5:31 AM, Richard Kettlewell wrote:
Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes:
But, really, they're just temp files the parent process can access.
Pipes *could* be implemented with temporary disk files, at least to an >>>> extent, but as far as I can tell, they're not.
“Temporary files the parent can access” is not a good model for a
couple of reasons:
* The semantics are different. Bytes read from a regular file are
still there to be read again if you rewind the file; bytes read from
a pipe are gone. Empty/full files behave differently to empty/full
pipes.
* Temporary regular files can already be accessed by other processes
by name, by file descriptor inheritance, or file descriptor passing.
Didn't say temp disk files were necessarily SUPERIOR,
Indeed. You said they’re really the same, which they’re not.
just that they CAN do most of the stuff pipes are used for and in an
easier user/code-friendly fashion.
There’s certainly an overlap in the end goals you can meet with them,
but even within that overlap they’re used in slightly different ways.
SIZE is almost unlimited too.
Capacity is one of the ways in which they are very different, already
alluded to above.
Anyway, I'd made some TCP/UDP servers but the parent needed
to know the status of the children in a little more detail
than just a tiny return code - might want to terminate the
child if it'd been idle for awhile, might want to know how
much bandwidth was being used, might want to pick a good
time to do some maint routines, might want to know WHO the
connections were from. Pipes were the (relatively) easy
'C'-approved method and did the job very well.
I’ve no idea what you think “’C’-approved” means. C is a programming
language, not a set of guidelines. Pipes are an OS concept, not
appearing in the C language standard.
As I said somewhere, if your child processes are sending megabytes
back to the parent you're DOING SOMETHING WRONG.
On Sun, 17 Nov 2024 22:50:41 -0500, 186282@ud0s4.net wrote:
As I said somewhere, if your child processes are sending megabytes
back to the parent you're DOING SOMETHING WRONG.
Says the one who has no clue how to write real-world programs.
On 11/18/24 1:06 AM, Lawrence D'Oliveiro wrote:
On Sun, 17 Nov 2024 22:50:41 -0500, 186282@ud0s4.net wrote:
As I said somewhere, if your child processes are sending megabytes
back to the parent you're DOING SOMETHING WRONG.
Says the one who has no clue how to write real-world programs.
Am I supposed to say something horrible about
you now ?
Nope. Won't. I'm sick of 'The Wars'.
Clue - I've writ 'real world programs' and
got paid well for them from the punch-card
days on. I did it my way, for my reasons,
my 'vision'.
And so did you.
I've no idea why using IPC to send megabytes of data between different processes is wrong.
Although to be fair we very rarely used pipes, directly, almost never.
It was always something like REST or message queues.
On Mon, 18 Nov 2024 09:20:23 +0000, Pancho wrote:
I've no idea why using IPC to send megabytes of data between different
processes is wrong.
It is something I have done. It’s perfectly commonplace.
Although to be fair we very rarely used pipes, directly, almost never.
I have used pipes, I have used Unix sockets, I have used network sockets.
If you are running a Linux GUI, then almost certainly it is built on D-Bus
as a high-level IPC mechanism that is used as a core component. That is designed to run over Unix sockets. It is not itself designed for high- bandwidth data transfers; if you want to do that, you can exchange your
own D-Bus messages to set up custom pipe or Unix socket connections
between bus peers.
It was always something like REST or message queues.
Message queues are an OS-provided primitive, but REST is not -- that is a protocol, not a transport. What transport(s) did you use for that? I would assume network connections.
I do remember looking at named pipes and deciding it was appropriate for
some task, but I have no memory of actually implementing it. Which could
mean it just worked and I never thought about it again, or it could mean
I didn't do it.
On 18/11/2024 11:05, Pancho wrote:
I do remember looking at named pipes and deciding it was appropriate
for some task, but I have no memory of actually implementing it. Which
could mean it just worked and I never thought about it again, or it
could mean I didn't do it.
Similar here.
I've tended to use ramdisk files ... for interprocess communication. Not idiot proof, but can be made fit for purpose.
I don't know if Linux provides message queues as a primitive, or not. I
meant I used message queue protocols (MQTT,zeroMQ, ActiveMQ).
On 11/18/24 13:45, The Natural Philosopher wrote:
On 18/11/2024 11:05, Pancho wrote:
I do remember looking at named pipes and deciding it was appropriate
for some task, but I have no memory of actually implementing it.
Which could mean it just worked and I never thought about it again,
or it could mean I didn't do it.
Similar here.
I've tended to use ramdisk files ... for interprocess communication.
Not idiot proof, but can be made fit for purpose.
I guess simpler than shared memory sections.
One of my golden rules of programming was - show me some RAM and I will squander it on a cache. :-) Although, my crime was mainly in memory databases.
I guess simpler than shared memory sections.
One of my golden rules of programming was - show me some RAM and I will squander it on a cache. Although, my crime was mainly in memory
databases.
On 11/18/24 06:51, 186282@ud0s4.net wrote:
On 11/18/24 1:06 AM, Lawrence D'Oliveiro wrote:
On Sun, 17 Nov 2024 22:50:41 -0500, 186282@ud0s4.net wrote:
As I said somewhere, if your child processes are sending megabytes
back to the parent you're DOING SOMETHING WRONG.
Says the one who has no clue how to write real-world programs.
Am I supposed to say something horrible about
you now ?
Nope. Won't. I'm sick of 'The Wars'.
Clue - I've writ 'real world programs' and
got paid well for them from the punch-card
days on. I did it my way, for my reasons,
my 'vision'.
And so did you.
I mainly did as I was told. In large political organisations following
your own vision can be problematic. You have to fight for a vision.
I've no idea why using IPC to send megabytes of data between different processes is wrong. That is what many service-orientated architectures
do. The moment you have a persistence service it is likely to happen.
Although to be fair we very rarely used pipes, directly, almost never.
It was always something like REST or message queues.
On 18/11/2024 11:05, Pancho wrote:
I do remember looking at named pipes and deciding it was appropriate
for some task, but I have no memory of actually implementing it. Which
could mean it just worked and I never thought about it again, or it
could mean I didn't do it.
Similar here.
I've tended to use ramdisk files ... for interprocess communication. Not idiot proof, but can be made fit for purpose.
yer passing "blocks of information" between processes.
...
As I said somewhere, if your child processes are sending
megabytes back to the parent you're DOING SOMETHING WRONG.
A named pipe let mplayer write to a named file.
Temporary files on a RAMdisk are fine (but slower).not if it never gets to disk, but is all in cache
On Mon, 18 Nov 2024 11:05:03 +0000, Pancho wrote:
I don't know if Linux provides message queues as a primitive, or not. I
meant I used message queue protocols (MQTT,zeroMQ, ActiveMQ).
https://www.softprayog.in/programming/interprocess-communication-using- system-v-message-queues-in-linux
https://www.softprayog.in/programming/interprocess-communication-using- posix-message-queues-in-linux
I've only used System V queues. Neither work like ActiveMQ.
Dunno why everybody seems so keen to slag anybody
who doesn't do it/see it exactly like some high-holy
manual from 1982 says you're supposed to. That's
no fun !
That has a knock on effect that I don't really
understand the behaviour of programs which do use pipes. I'm presuming
bash commands uses pipes.
(I think it was a topic shift to applications of *nix pipes...?)
Eli the Bearded <*@eli.users.panix.com> wrote:
Okay, I give up.(I think it was a topic shift to applications of *nix pipes...?)
1. How does that relate to EBCDIC?
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
Pipes are good.
But, really, they're just temp files the parent
process can access.
But, really, they're just temp files the parent process can access.
This is a multi-part message in MIME format. --------------cDOk308Xy6TMkzB8MsXpyDQY
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit
On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
Pipes are good.
But, really, they're just temp files the parent
process can access.
Pipes *could* be implemented with temporary disk files, at least to an extent, but as far as I can tell, they're not.
Quoting from this page:
https://www.geeksforgeeks.org/piping-in-unix-or-linux/#
In Linux, a pipe is not a regular file but a type of inter-process
communication (IPC) mechanism that acts as a buffer, which can be
used to connect the output of one process to the input of another.
Although pipes are not files, they are implemented using file
descriptors and share many behaviors with files. They exist only in
memory and do not have a presence in the file system, unlike regular
files.
Louis
On 11/15/2024 12:49 AM, 186282@ud0s4.net wrote:
On 11/14/24 9:05 PM, Lawrence D'Oliveiro wrote:
On Thu, 14 Nov 2024 16:09:07 -0800, John Ames wrote:
(I think it was a topic shift to applications of *nix pipes...?)
Oh shelly boy, the pipes, the pipes are calling ...
Pipes are good.
But, really, they're just temp files the parent
process can access.
Pipes *could* be implemented with temporary disk files, at least to an extent, but as far as I can tell, they're not.
Quoting from this page:
https://www.geeksforgeeks.org/piping-in-unix-or-linux/#
In Linux, a pipe is not a regular file but a type of inter-process
communication (IPC) mechanism that acts as a buffer, which can be
used to connect the output of one process to the input of another.
Although pipes are not files, they are implemented using file
descriptors and share many behaviors with files. They exist only in
memory and do not have a presence in the file system, unlike regular
files.
There are also "named pipes" aka FIFOs.
IF you are doing multi-threaded/process style pgms then you almost
HAVE to use them if you want to xmit more than a few bytes between
parents/children. A few years back I was experimenting with TCP/UDP
servers and found that it could be very useful to transmit a few
dozen bytes worth of active data between parents/children.
SO ... learn yer pipes !
On Sat, 16 Nov 2024 00:37:35 -0500, 186282@ud0s4.net wrote:
IF you are doing multi-threaded/process style pgms then you almost
HAVE to use them if you want to xmit more than a few bytes between
parents/children. A few years back I was experimenting with TCP/UDP
servers and found that it could be very useful to transmit a few
dozen bytes worth of active data between parents/children.
SO ... learn yer pipes !
Message queues and shared memory are handy for IPC too. I don't think Microsoft ever figured either out. What they call message queues are completely different.