Hi community, just my 2cents on that topic:
I wrote a simple test (modified from the threads module doc) to explore the
signalling behaviour. If signal is called first, the signal is not lost and a
later wait() is not locking (on my machine). would be nice to share experience
on other platforms..
here is the code:
# example taken from the module threads doc and modified for one child
thread
# to explore the semantics of lock and signal
# code tested only on windows10 with a single core machine
# compiled with --d:release --threads:on
# Nim Compiler Version 0.17.3 (2017-09-16) [Windows: amd64]
# Copyright (c) 2006-2017 by Andreas Rumpf
# git hash: 12af4a3f8ac290f5c6f7d208f1a1951a141449ff
# active boot switches: -d:release
# if the signal is called before the wait is executed
# the signal is not lost, and the code is not locking
import locks,os
# globals
var
thr: Thread[int] # don´t know if there is a untyped thread possible
cLock: Lock
lockCond: Cond
proc threadFunc (param : int) {.thread.} =
signal(lockCond) # first signal call
signal(lockCond) # if you signal twice the second signal is lost (no
queue)
echo "childthread: signal executed"
initLock(cLock)
initCond(lockCond)
createThread(thr, threadFunc,0)
echo "mainthread:begin"
sleep(5000) # ensure that the signal of the childthread is called first
echo "start waiting"
wait(lockCond,cLock)
# wait(lockCond,cLock)
# uncomment to check if there is a queue behind; on windows the (expected)
# behaviour is a deadlock for the second wait (second signal call is lost)
echo "end waiting"
joinThreads(thr) # should not block if the childthread is already finished
deinitLock(cLock)
deinitCond(lockCond)
echo "end"
