This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Help: looking for equivalent syscall to shutdown() but for unix pipes
- From: Alexandre Bique <bique dot alexandre at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 18 Jan 2019 15:41:50 +0100
- Subject: Re: Help: looking for equivalent syscall to shutdown() but for unix pipes
- References: <CAP737oKftbrxDDRX7RM_PBVTcx54d+j=Vz5LJysq=3D0CNeRvw@mail.gmail.com> <87r2dbu0t8.fsf@oldenburg2.str.redhat.com> <CAP737o+A0OoRM1D1QR6=cg1i+wu37q2NU9bxOskEtdSfbqD=3w@mail.gmail.com> <871s5aqnqn.fsf@oldenburg2.str.redhat.com>
On Fri, Jan 18, 2019 at 11:11 AM Florian Weimer <fweimer@redhat.com> wrote:
> > I was thinking that I could use poll on the file descriptor and then
> > just check a flag before reading the pipe. Now to wake up the poll()
> > syscall I would need an eventfd which is an additional opened file,
> > not awesome.
>
> How do you detect that you are at the end of the stream if you do not
> have an EOF indicator? If the other process crashes for any reason, you
> are left with truncated data if you don't have an EOF indicator.
We'll get an EOF from the OS, because the write end of the pipe has been closed.
> In the past, I dealt with the crash problem by launching the producer
> process from the consumer, and commit to processing the data in the
> consumer only after the producer has exited with zero status. Maybe
> that's an approach you could use?
We managed to make sure that the producer closes the write end of the
pipe. So we don't have the issue anymore, but the problem is still
valid I think and the pipe needs a shutdown equivalent.
Thank you,
--
Alexandre Bique