Cache pointer updates are not thread safe

[kayrus]

Multiple threads may cause simultaneous cache updates, e.g.

schwift/account.go

Line 113 in 80c09ef

a.headers = &headers

schwift/account.go

Line 120 in 80c09ef

a.headers = nil

schwift/account.go

Line 197 in 80c09ef

a.caps = &caps

schwift/container.go

Line 96 in 80c09ef

c.headers = &headers

schwift/container.go

Line 96 in 80c09ef

c.headers = &headers

schwift/object.go

Line 116 in 80c09ef

o.headers = hdr

schwift/object.go

Line 413 in 80c09ef

o.headers = nil

schwift/object.go

Line 443 in 80c09ef

o.symlinkHeaders = &newHeaders

schwift/object.go

Line 445 in 80c09ef

o.headers = &newHeaders

schwift/object.go

Line 559 in 80c09ef

o.headers = o.symlinkHeaders

[majewsky]

As a stop-gap measure, bd1c745 adds documentation that these methods are not thread-safe on the same object. I'm willing to take a PR that guards these fields with RwLocks.

[majewsky]

Besides, it would be helpful to know your usecase. I didn't really anticipate objects to be held for a long time (except for Account where your concern is entirely valid) or shared between goroutines. It may be enough to clone objects by obj2 := obj.Container().Object(obj.Name()) before sharing them with another goroutine.

[kayrus]

use case is simple. Try to run https://github.com/sapcc/swift-http-import in multiple workers: https://github.com/sapcc/swift-http-import#performance

[majewsky]

I had another look to be sure. When run with a multi-job config, s-h-i treats all jobs as wholly separate, so we're talking about different schwift.Container instances. While there could be a concern to change that code structure to allow for more data sharing between jobs, it's not a concern of Schwift and won't be solved by the issue described herein. This is a concern of s-h-i's code structure.