Krasimir Angelov wrote:
This fixes the problem but after that the RTS blocks with waitCondition
at line 401 in Capability.c. The trace messages are with +RTS -Ds are:
ACQUIRE_LOCK(0x64FDC130) Stable.c 248
RELEASE_LOCK(0x64FDC130) Stable.c 251
ACQUIRE_LOCK(0x64FDCE50) Schedule.c 2689
sched (task 00000EF8): allocated 1 capabilities
RELEASE_LOCK(0x64FDCE50) Schedule.c 2722
ACQUIRE_LOCK(0x64FDCDF0) Storage.c 132
RELEASE_LOCK(0x64FDCDF0) Storage.c 256
ACQUIRE_LOCK(0x64FDCE50) RtsAPI.c 560
sched (task 00000EF8): new task (taskCount: 1)
RELEASE_LOCK(0x64FDCE50) RtsAPI.c 562
ACQUIRE_LOCK(0x64FDD128) Capability.c 387
sched (task 00000EF8): returning; I want capability 0
RELEASE_LOCK(0x64FDD128) Capability.c 395
sched (task 00000EF8): returning; got capability 0
ACQUIRE_LOCK(0x64FDCE50) Schedule.c 2425
RELEASE_LOCK(0x64FDCE50) Schedule.c 2429
sched (task 00000EF8): created thread 1, stack size = f2 words
sched (task 00000EF8): new bound thread (1)
sched (task 00000EF8): ### NEW SCHEDULER LOOP (task: 01D8FD50, cap: 64FDD040)
sched (task 00000EF8): ### Running thread 1 in bound thread
sched (task 00000EF8): -->> running thread 1 ThreadRunGHC ...
sched (task 00000EF8): thread 1 did a safe foreign call
ACQUIRE_LOCK(0x64FDD128) Schedule.c 2212
sched (task 00000EF8): starting new worker on capability 0
ACQUIRE_LOCK(0x01D8FE10) Task.c 245
sched (task 00000EF8): new worker task (taskCount: 2)
RELEASE_LOCK(0x01D8FE10) Task.c 265
RELEASE_LOCK(0x64FDD128) Schedule.c 2218
sched (task 00000EF8): thread 1: leaving RTS
ACQUIRE_LOCK(0x64FDD128) Capability.c 387
sched (task 00000EF8): returning; I want capability 0
RELEASE_LOCK(0x64FDD128) Capability.c 398
ACQUIRE_LOCK(0x01D8FD70) Capability.c 401
RELEASE_LOCK(0x01D8FD70) win32/OSThreads.c 75
I also have added optional debug messages to ACQUIRE_LOCK/RELEASE_LOCK
for Windows like they have been added for Linux. The applied patch is attached.
Here I think is the problem. The designers of Windows saw fit to
implement the following strange behaviour of threads (from the
CreateThread() docs):
During process startup and DLL initialization routines, new threads
can be created, but they do not begin execution until DLL
initialization is done for the process.
the GHC RTS is relying on being able to create a new thread, and
handshaking with the new thread. However, it deadlocks because the new
thread doesn't run.
