03-23-04 12:34 AM
<nospam@nospam.com> wrote in message news:c3ns5h0md8@drn.newsguy.com...
> This seems like a fairly easy question, but I haven't found the answer out
there
> yet.
>
> What I have is a program that is using pipes as an IPC mechanism between
two
> processes. I'm using the file descriptor interface (i.e. pipe/read/write)
and
> not the buffered I/O interface (fopen/fread/fwrite). My application is
sort of a
> producer/consumer situation.
>
> What I want to do is to force the "producer" to wait until the consumer
has read
> all of the outstanding bytes in the pipe. As I understand, there is a
buffer in
> the kernel (we're talking linux here) which holds the outstanding bytes in
the
> pipe. I want the producer to be able to wait until that buffer is empty
(i.e.
> the consumer has removed the bytes from the pipe using read()).
>
> Alternatively, if I could figure out how many bytes are outstanding in
this
> buffer, I could just wait until it is empty.
>
> Thanks
> Scott
>
You can probably use the fstat system call on one of the pipe file
descriptors and use the size as the number of bytes in the pipe, but this is
non-portable. (Which may not matter in your application.) Also, it has the
potential disadvantage that the producer will be in a busy-wait loop waiting
for the size to go to zero.
A similar technique, more portable but with the same busy-wait problem, is
for the producer to use select/poll on the WRITE end of the pipe, until
select/poll indicates that a reader would block. But, this is using
select/poll backwards from the usual way, and is awkward to implement
efficiently.
A portable and potentially more efficient way to do it is to use a separate
pipe, flowing the other way, for the consumer to use to tell the producer
when the consumer is finished.
One of the least attractive ways is to use a signal, because using signals
is usually a least attractive way. (Too many problems dealing with signals.)
--
Marc Rochkind
"Advanced UNIX Programming" (publishing April 2004)
www.basepath.com/aup
[ Post a follow-up to this message ]
|