On Tuesday, April 28, 2020 at 12:05:00 AM UTC-7, Liam wrote:
>
>
>
> On Monday, April 27, 2020 at 10:00:52 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Mon, Apr 27, 2020 at 6:59 PM Liam <networ...@gmail.com> wrote:
>> >
>> > On Monday, April 27, 2020 at 5:56:52 PM UTC-7, Ian Lance Taylor wrote:
>> >>
>> >> On Mon, Apr 27, 2020 at 5:10 PM Liam <networ...@gmail.com> wrote:
>> >> >
>> >> > On Monday, April 27, 2020 at 4:22:41 PM UTC-7, Ian Lance Taylor
>> wrote:
>> >> >>
>> >> >> On Sun, Apr 26, 2020 at 4:55 PM Liam <networ...@gmail.com> wrote:
>> >> >> >
>> >> >> > During an io.Copy() where the Writer is a TCPConn and the Reader
>> is a 200K disk file, my code may concurrently Write() on the same TCPConn.
>> >> >> >
>> >> >> > I see the result of the Write() inserted into the result of the
>> io.Copy(). I had the impression that was impossible, but I must be
>> mistaken, as the sendfile(2) docs read:
>> >> >> >
>> >> >> > Note that a successful call to sendfile() may write fewer bytes
>> than requested; the caller should be prepared to retry the call if there
>> were unsent bytes.
>> >> >> >
>> >> >> > Could someone confirm that one must indeed synchronize concurrent
>> use of tcpConn.Write() and io.Copy(tcpConn, file)?
>> >> >>
>> >> >> Synchronization should not be required. internal/poll.Sendfile
>> >> >> acquires a write lock on dstFD, which is the TCP socket. That
>> should
>> >> >> ensure that the contents of an ordinary Write (which also acquires
>> a
>> >> >> write lock) should not interleave with the sendfile data.
>> >> >>
>> >> >> That said, if the sendfile system call cannot be used for whatever
>> >> >> reason, the net package will fall back on doing ordinary Read and
>> >> >> Write calls. And those Write calls can be interleaved with other
>> >> >> Write calls done by a different goroutine. I think that is
>> probably
>> >> >> permitted, in that io.Copy doesn't promise to not interleave with
>> >> >> simultaneous Write calls on the destination.
>> >> >>
>> >> >> So in the general case you should indeed use your own locking to
>> avoid
>> >> >> interleaving between io.Copy and a concurrent Write.
>> >> >
>> >> >
>> >> > Thanks for the details. Where could I add a Println() to reveal why
>> it doesn't call poll.Sendfile()?
>> >> >
>> >> > I expect this system to use sendfile(2). The file is a normal file
>> on a local partition (running on a Digital Ocean Droplet).
>> >> >
>> >> >
>> >> > /etc/fstab has:
>> >> > UUID=[omitted] / ext4 defaults 1 1
>> >> >
>> >> >
>> >> > $ df -h
>> >> > Filesystem Size Used Avail Use% Mounted on
>> >> > devtmpfs 981M 0 981M 0% /dev
>> >> > tmpfs 996M 0 996M 0% /dev/shm
>> >> > tmpfs 996M 436K 995M 1% /run
>> >> > tmpfs 996M 0 996M 0% /sys/fs/cgroup
>> >> > /dev/vda1 59G 5.7G 51G 11% /
>> >> > tmpfs 200M 0 200M 0% /run/user/0
>>
>
> Well this is a surprise... Added some println()s
>
> // my network setup
> aCfgTcp := net.ListenConfig{KeepAlive: -1}
> aListener, err := aCfgTcp.Listen(nil, iConf.Listen.Net,
> iConf.Listen.Laddr)
> if err != nil { return err }
> aCert, err := tls.LoadX509KeyPair(iConf.Listen.CertPath,
> iConf.Listen.KeyPath)
> if err != nil { return err }
> aCfgTls := tls.Config{Certificates: []tls.Certificate{aCert}}
> aListener = tls.NewListener(aListener, &aCfgTls)
>
I left out my accept loop:
var aConn net.Conn
for {
aConn, err = aListener.Accept()
...
Is this the root cause, as net.Listener only provides Accept() (Conn,
error), and net.Conn doesn't provide ReadFrom()?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/2e4aba99-fa0a-4898-94f2-5af8c57e39af%40googlegroups.com.
