60fc88a09c
This test runs fine almost all of the time on systems with 1 processor, which were the norm when the test was written and are still the way that the Qt Continuous Integration system works as of today. But it falls flatly on multi-processor systems. The root of the problem is that QSystemSemaphore recreates the semaphore if it disappears underneath it. However, the recreation process is not thread-safe at all: if two threads race to recreate it, weird things might happen. strace on Linux shows that a thread got stuck trying to acquire the semaphore: <... nanosleep resumed> NULL) = 0 stat("/tmp/qipc_systemsem_market5c9f73af73334ffe350c60ec076e5744db0ecda3", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0 stat("/tmp/qipc_systemsem_market5c9f73af73334ffe350c60ec076e5744db0ecda3", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0 semget(0x51001388, 1, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File exists) semget(0x51001388, 1, IPC_CREAT|0600) = 114786308 semop(114786308, {{0, -1, SEM_UNDO}}, 1 <unfinished ...> This problem does not happen if the creation and destruction of the QSharedMemory (which uses QSystemSemaphore) does not race with other threads or processes attaching and detaching. For the threads test it's easy. For the processes, we use stdin and stdout as a communication channel. Change-Id: Ie11b135431d4abfc59234654848b67f622eb03c9 Reviewed-by: Richard J. Moore <rich@kde.org> |
||
---|---|---|
bin | ||
config.tests | ||
dist | ||
doc | ||
examples | ||
lib | ||
mkspecs | ||
qmake | ||
src | ||
tests | ||
tools | ||
util | ||
.gitattributes | ||
.gitignore | ||
.qmake.conf | ||
.tag | ||
configure | ||
configure.bat | ||
header.BSD | ||
header.FDL | ||
header.LGPL | ||
header.LGPL-ONLY | ||
INSTALL | ||
LGPL_EXCEPTION.txt | ||
LICENSE.FDL | ||
LICENSE.GPL | ||
LICENSE.LGPL | ||
LICENSE.PREVIEW.COMMERCIAL | ||
qtbase.pro | ||
sync.profile |