Re: The joy of pipes

On 11/17/24 3:42 AM, Richard Kettlewell wrote:

"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.

   Umm ... they're all "blocks of information", however
   stored/accessed. The little details are, well, the
   little details.

   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.

   As I said somewhere, if your child processes are sending
   megabytes back to the parent you're DOING SOMETHING WRONG.
   Using files -vs- pipes you CAN xmit mass quantities of
   data between parent/child and or child/child but that's
   probably not the best way to write your app. Leave the
   parent to do 'parent stuff' mostly.
   But somebody, somewhere, for some reason, MIGHT wanna
   do it differently ... and maybe, in context, it's for
   a good reason. I'm not gonna piss all over them.

   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.

   The 'C' Way IS a sort of 'philosophy' I think ... an
   approach to programming and data-use. Most every lang
   is that way. The Algol/Pascal/Modula approach is a bit
   different, another 'look and feel' to all the issues.
   Everybody has what they think is "The Best Way" - of
   thinking/doing. Otherwise we shoulda all stuck with ASM.
   No FORTRAN, no COBOL, no LISP, no Algol, no 'C' ....
   The way 'C' does interprocess comms was writ in, by and
   for 'C'. As such if you're doing 'C' you will have the
   best luck and least angst going with the flow.
   You can also send/receive between parent/child and
   such by passing socket info. See :
https://stackoverflow.com/questions/14427898/how-can-i-pass-a-socket-from-parent-to-child-processes