[PATCH 2 of 4 RFC] chgcache: implement simple IPC mechanism

[Yuya Nishihara]

On Tue, 14 Feb 2017 11:05:00 -0800, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-02-14 22:49:34 +0900:
> > On Mon, 13 Feb 2017 09:46:21 -0800, Jun Wu wrote:
> > > Excerpts from Yuya Nishihara's message of 2017-02-13 23:00:25 +0900:
> > > > Why not os.pipe()?
> > > >
> > > > We share the same (dup-ed) file descriptors. In this case, the write end can
> > > > be used by many forked processes, but IIRC the read end can't. Only one
> > > > reader can read out a message. So I think there's no reason to set up a
> > > > full duplex IPC channel.
> > > 
> > > Duplex IRC is not needed. But I do want to use DGRAM.
> > > 
> > > DGRAM makes it impossible to send incomplete messages. I think that makes
> > > the code simpler and maybe more efficient.
> > 
> > Ok.
> > 
> > Perhaps you won't need the suffix as datagram socket is message oriented?
> 
> Right. It's not needed if we can figure out the message length first.

I don't know the datagram unix socket, but if it acts the same as UDP socket,
recv() will read exactly one message. Contiguous messages won't be streamed.

> That could be done via "fcntl.ioctl(fd, termios.FIONREAD, buf)", which won't
> work on Windows. I think that's fine since we have so many non-Windows code
> already.

Sure. chg will never run on Windows.