>We use named pipe, for the communication between two processes running
>on the Solaris box. One process keeps pumping in huge amount of data,
>and the other server process receives this data and performs further
>processing.
>
>As huge amount of data is sent over the named pipe, I'm just concerned
>whether there will be a buffer limit problem(at sender & receiver
>sides) due to that.

Why do you care? If you fill the buffer, your writer will wait until
the whole write will fit. You can't write "too fast". A named pipe
isn't like UDP where a massive blast of sending results in large
amounts of lost packets.

Instances where you might care include the possible need for atomic
writes over the pipe (meaning you have two or more processes writing).

Another possible bottleneck involves a bi-directional pipe where
you can get into a deadlock with both processes trying to send and
neither trying to read. Avoid this design if possible.

There are possible performance issues but I'd be more worried about
the receiver being the bottleneck.

>Can anybody tell me how I can find out the
>limitation by Solaris, and how exactly I can increase tune this limit?

On Aug 18, 2:22 am, "qazmlp1...@rediffmail.com"
wrote:
> We use named pipe, for the communication between two processes running
> on the Solaris box. One process keeps pumping in huge amount of data,
> and the other server process receives this data and performs further
> processing.
>
> As huge amount of data is sent over the named pipe, I'm just concerned
> whether there will be a buffer limit problem(at sender & receiver
> sides) due to that. Can anybody tell me how I can find out the
> limitation by Solaris, and how exactly I can increase tune this limit?

I think it's limited to one page, generally 4096 bytes though the
exact value is obtainable through 'getpagesize'. I don't think you
can change it from user space. And yes, you *can* run into overrun
problems *if* for some reason a write descriptor is in non-blocking
mode, which is really only useful if you *want* a buffer backup to
cause something other than an indefinite wait for it to clear up, or
if you have a socket and want reading to be non-blocking. You
probably also want to handle or ignore 'SIGPIPE' because a write to a
pipe no longer open for reading will usually cause one.
Kevin P. Barry