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: Florian Weimer <fweimer at redhat dot com>
- To: Alexandre Bique <bique dot alexandre at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 18 Jan 2019 11:11:28 +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>
* Alexandre Bique:
> On Thu, Jan 17, 2019 at 9:48 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alexandre Bique:
>>
>> > I'm having an issue with pipes in a multi-threaded application.
>> >
>> > I have one thread (T1) reading a pipe in a loop, and I'd like to close
>> > that pipe from an other thread (T2) and join T1.
>> >
>> > With sockets I'd use shutdown(fd, SHUT_RD).
>>
>> I don't think something like this exists for pipes.
>>
>> > What do you recommend?
>>
>> You need some sort of framing layer, so that you can transmit both data
>> and an EOF indicator.
>
> Thank you very much.
>
> I'm not very enthusiast with the idea of sending an EOF message,
> because the original producer comes from an other process, so there
> could be all sorts of corrupted data over the pipe, unless maybe it is
> using packets instead of streams. But in our case it is using streams.
>
> 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.
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?
Thanks,
Florian