"I. Szczesniak" wrote: > On 7/10/09, Garrett D'Amore <gdam...@sun.com> wrote: > > Bob Friesenhahn wrote: > > > On Fri, 10 Jul 2009, Roland Mainz wrote: > > > > > Some applications may misbehave or lock-up if the size of the pipe > > > > > buffer is changed. > > > > > > > > Erm... why ? > > > > > > You have already noticed that the size is hard-coded in Solaris > > applications (by PIPE_BUF) since the dawn of time. Pipes offer properties > > such as atomic reads and writes. PIPE_BUF declares the maximum size of an > > atomic write. Some applications depend on this FIFO behavior for message > > passing. > > > > > > You should feel happy that Solaris is using 5120 rather than 512 like > > FreeBSD. > > > > Having an ioctl that offers making this tunable could be used by shells > > when constructing pipelines between applications that just use pipes to > > redirect stdin/stdout. Such a use should not be sensitive to changes in > > pipe size, since the applications generally don't even know (or care) that > > their stdio is using a pipe. > > I don't think this is a practical solution.
It would be a solution which requires to hack each single shell... that's the part which I do not like. I would like to get a solution which works for _all_ applications. > It requires cooperation > from all application, i.e. shells. At least the bash authors are > adamant 'not to add more specific API crap for a proprietary and dying > Solaris'. Erm... could we please not "warm up" the old stories/incidents/flamewars, please (this one is old and AFAIK even predates OpenSolaris) ? > > I agree that we should *not* have the pipe(2) system call change the system > > default... that would be potentially destructive to many applications, as > > you note. > > The pipe users expect to do atomic writes and reads in chunks of > PIPE_BUF bytes. Increasing the pipe buffer to n*PIPE_BUF (e.g. 5120, > 10240, 20480, 40960, ...) is safe. Mhhh... that may work but it depends on whether (legacy) applications use |PIPE_BUF|(=5120bytes) as hardcoded maximum |read()|/|write()| size. I'm not sure what happens if the application writes 5120 bytes in one chunk and then writes another byte and assumes the |write()| call will block until the consumer has read the first 5120-byte chunk (OkOk... AFAIK no application should expect that pipes work that way). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
