Messages in this thread | | | Date | Wed, 23 Jul 2003 14:14:57 -0400 (EDT) | From | Glenn Fowler <> | Subject | Re: kernel bug in socketpair() |
| |
On Wed, 23 Jul 2003 10:31:35 -0700 David S. Miller wrote: > Interesting.
> I looked at the bash code, and it uses pipes with /dev/fd/N, and for > /dev/fd/N which are pipes the open should work under Linux.
> This is what David Korn said in his original report.
> I guess the part that is left is the fchmod() issue which exists > because one inode is used to implement both sides of the pipe under > Linux.
> Was the idea to, since fchmod() on pipes modified both sides, > to use UNIX domain sockets to implement this? And that's how > you discovered the /dev/fd/N failure for sockets?
fchmod() came into play with socketpair() to get the fd modes to match pipe(); its not needed with pipe()
we use socketpair() to allow efficient peeking on pipe input (via recv()), where peek means "read some data but don't advance the read/seek offset" btw, this is on systems that don't allow ioctl(I_PEEK) on pipe() fds; if there is a way to peek pipe() data on linux then we can switch back to pipe() and be on our way
> Another idea is to use named unix sockets. Can that be > sufficient to solve your dilemma?
named sockets seem a little heavyweight for this application
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |