Thread (16 messages) 16 messages, 4 authors, 2003-07-23

Re: kernel bug in socketpair()

From: Glenn Fowler <hidden>
Date: 2003-07-23 18:01:16
Also in: lkml

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help