You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Work around #615, and add support for building with the Static Linux SDK
* Factor out threading abstraction for BatchWorkers and use normal Thread subclass on Apple platforms
// https://github.com/open-telemetry/opentelemetry-swift/issues/615 prevents Linux builds from succeeding due to a regression in Swift 6 when subclassing Thread. We can work around this by using a block based Thread.
5
+
classWorkerThread{
6
+
varthread:Thread!
7
+
8
+
varisCancelled:Bool{
9
+
self.thread.isCancelled
10
+
}
11
+
12
+
init(){
13
+
self.thread =Thread(block:{[weak self]in
14
+
self?.main()
15
+
})
16
+
}
17
+
18
+
func main(){}
19
+
20
+
func start(){
21
+
self.thread.start()
22
+
}
23
+
24
+
func cancel(){
25
+
self.thread.cancel()
26
+
}
27
+
}
28
+
#else
29
+
// Builds using a Swift older than 5 or on a non-Linux OS should be able to use the normal Thread subclass
// After the BatchWorker is shutdown, it will continue waiting for the condition variable to be signaled up to the maxScheduleDelay. Until that point the exporter won't be deallocated.
122
+
sleep(UInt32(ceil(maxScheduleDelay +1)))
123
+
// Interestingly, this will always succeed on macOS even if you intentionally create a strong reference cycle between the BatchWorker and the Thread's closure. I assume either calling cancel or the thread exiting releases the closure which breaks the cycle. This is not the case on Linux where the test will fail as expected.
// Both the provider and the tracer retain the exporter, so we need to clear those out in order for the exporter to be deallocated.
253
+
tracerSdkFactory =TracerProviderSdk()
254
+
tracer =nil
255
+
}
256
+
257
+
// After the BatchWorker is shutdown, it will continue waiting for the condition variable to be signaled up to the maxScheduleDelay. Until that point the exporter won't be deallocated.
258
+
sleep(UInt32(ceil(maxScheduleDelay +1)))
259
+
// Interestingly, this will always succeed on macOS even if you intentionally create a strong reference cycle between the BatchWorker and the Thread's closure. I assume either calling cancel or the thread exiting releases the closure which breaks the cycle. This is not the case on Linux where the test will fail as expected.
0 commit comments