FreeBSD: Test Failed: dispatch_workqueue

[etcwilde]

==================================================
[TEST] Dispatch workqueue
[PID] 78314
==================================================


[BEGIN] dispatch_get_global_queue
        Actual: 0x8216f87c0
        Expected: 0x8216f87c0
[PASS] dispatch_get_global_queue

[BEGIN] flag
        Actual: 0
        Expected: 1
[FAIL] flag

It looks like dispatch_get_global_queue is returning a null pointer on FreeBSD.

[akmorrison]

From the test output it looks like the internal workqueue is failing to overcommit the CPUs, not that dispatch_get_global_queue is returning NULL. What environment is this running in? There was an issue with this test in linux containers (#877) where we were calculating core count via sysconf, which returns an incorrect value in containers - we might be hitting something similar here. Looks like on freebsd we use sysctlbyname("hw.activecpu", ...).

Other possibility is that this is running into more timer issues - it looks like the internal workqueue implementation sets a 1s repeating timer to evaluate whether to overcommit the CPU, and if that deadline is miscalculated on freebsd, we won't overcommit here and we'd hit this failure.

[etcwilde]

This is on FreeBSD, so not running in a docker-like environment. sysconf returns the logical core count while sysctlbyname hw.activecpu returns the physical core count. Which value is this test actually intending to use? dwNumberOfProcessors and _SC_NPROCESSORS_ONLN are both the logical core count as well. That said, in this environment, I would expect the values to be the same.

[etcwilde]

Ah, yeah, I made this comment already: #861 (comment)

It looks like a different patch was applied to use hw.activecpu instead: #876.

[kevans91]

Ah, yeah, I made this comment already: #861 (comment)

It looks like a different patch was applied to use hw.activecpu instead: #876.

I note that hw.activecpu doesn't actually exist on FreeBSD, so you're presumably working off of stack garbage there. _SC_NPROCESSORS_ONLN or _SC_NPROCESSORS_CONF would be fine, or consulting cpuset_getaffinity.

[kevans91]

Related-ish, but _dispatch_hw_get_config could also largely take the defined(__linux__) && HAVE_SYSCONF path for FreeBSD as well. For _dispatch_hw_config_active_cpus, we do technically have a pthread_getaffinity_np, but I would imagine you're not dragging in libthr/pthreads -- our platform equivalent would be cpuset_getaffinity, but we also have a Linux-compatible sched_getaffinity if that could be used instead on both platforms. If not, here's a cpuset_getaffinity sample

[etcwilde]

Thanks for the input. Dispatch does pull in pthread, so it should be fine sticking to the defined(__linux__) && HAVE_SYSCONF path and using pthread_getaffinity_np.

[kevans91]

Thanks for the input. Dispatch does pull in pthread, so it should be fine sticking to the defined(__linux__) && HAVE_SYSCONF path and using pthread_getaffinity_np.

Ah, sorry about that- in hindsight, it seems obvious that Dispatch would wrap pthreads instead of trying to go neck-deep into the underlying primitives for every supported platform.