Help: looking for equivalent syscall to shutdown() but for unix pipes

[Alexandre Bique]

On Fri, Jan 18, 2019 at 1:56 PM Godmar Back <godmar@gmail.com> wrote:
> I agree with Florian that you need to think about the higher-level
> semantics and how you can reconcile the notion of a "stream" with
> absolutely no message boundaries with needing to know when the data
> has been sent completely.
>
> Pretty much any protocol that's layered on a byte stream transport has
> this: HTTP, for instance, creates message boundaries via a message
> length sent in the header.
>
> Waiting for the consumer to exit with zero of course raises potential
> buffering issues.  You can't wait to read until the consumer exits (or
> else you could deadlock), so you have to buffer, in which case you
> need to think about how much. But that's perhaps a problem you're
> facing anyway.

No we don't have buffering or communication issues at all.

After reading the mail, I wonder if I've described the issue correctly.

Let's say you have the following code:

int pipeFd;

void consumerThread()
{
  while (true)
  {
    ret = read(pipeFd, ...);

    // do something with ret and the data
  }
}

void stopConsumer()
{
  int fd = pipeFd;
  pipeFd = -1;
  close(fd);
  join(...);
}

You'll have a race here:

T1. load pipeFd from memory, put the args on the stack for the read
call, interrupted (before calling read)
T2. stopConsumer() -> waiting in join()
T3. open a file, which get the same fd as pipeFd previously had
T1. call reads but read from the newly opened file instead of the pipe
(very bad!!!)

And the fixed version would be:

void stopConsumerFixed()
{
  shutdown(pipeFd, SHUT_RD);
  join(...);
  close(fd);
}

If we play again the same scenario we get:

T1. load pipeFd from memory, put the args on the stack for the read
call, interrupted (before calling read)
T2. stopConsumer() -> waiting in join()
T3. open a file, which gets a new fd
T1. call reads but read gets EOF as the read is not possible anymore, returns.
T2. joins and close the fd.

Is that clear?

Cheers,
-- 
Alexandre Bique