Copy can now handle arbitrary nesting of streams, without knowing the
underlying type of either the source or destination.
It does this by attempting `SendTo` and `ReceiveFrom`, then if that is
not supported, falling back to nested copies in separate goroutines.
Signed-off-by: Solomon Hykes <solomon@docker.com>
StackSender forwards beam messages to a dynamic list of backend receivers.
New backends are stacked on top. When a message is sent, each backend is
tried until one succeeds. Any failing backends encountered along the way
are removed from the queue.
Signed-off-by: Solomon Hykes <solomon@docker.com>
* Copy is the beam equivalent of `io.Copy`
* `ReceiveFrom` is the beam equivalent of `io.ReadFrom`
* `SendTo` is the beam equivalent of `io.WriteTo`
Signed-off-by: Solomon Hykes <solomon@docker.com>
This introduces a superficial change to the Beam API:
* `beam.SendPipe` is renamed to the more accurate `beam.SendRPipe`
* `beam.SendWPipe` is introduced as a mirror to `SendRPipe`
There is no other change in the beam API.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
This is needed for Send/Recieve to correctly handle borders between
the messages.
The framing uses a single 32bit uint32 length for each frame, of which
the high bit is used to indicate whether the message contains a file
descriptor or not. This is enough to separate out each message sent
and to decide to which message each file descriptors belongs, even
though multiple Sends may be coalesced into a single read, and/or one
Send can be split into multiple writes.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
These are failing, and indicate things that need to be fixed. The
primarily problem is the lack of framing between beam messages.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
[solomon@docker.com: rebased on master]
Signed-off-by: Solomon Hykes <solomon@docker.com>
Instead of calling syscall.Close() on the fds in sendUnix() we call
Close() on the *os.File in Send(). Otherwise the fd will be closed, but
the *os.File will continue to live, and when it is finalized the
fd will be closed (which by then may be reused and can be anything).
This also adds a note to Send() the the file is closed.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Commands in the pipeline should either implement or pass-through command messages.
This amounts to a proof-of-concept implementation of the "pipeline"
design of Docker plugins.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
Grab forklock to make sure no forks accidentally inherit the new fds
before they are made CLOEXEC There is a slight race condition between
ReadMsgUnix returns and when we grap the lock, so this is not
perfect. Unfortunately There is no way to pass MSG_CMSG_CLOEXEC to
recvmsg() nor any way to implement non-blocking i/o in go, so this is
hard to fix.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Solomon Hykes
Alexander Larsson
Tianon Gravi