ta0kira / zeolite

Zeolite is a statically-typed, general-purpose programming language.
Apache License 2.0
18 stars 0 forks source link

`MutexLock` isn't unlocking `ThreadCondition` in `PrimesDemo`. #174

Closed ta0kira closed 3 years ago

ta0kira commented 3 years ago

Example:

example/primes/PrimesDemo: Failed condition: Error locking mutex: Resource deadlock avoided (error 35)
  From ThreadCondition.lock
  From MutexLock.lock
  From ThreadFlag.cancel at line 39 column 7 of "example/primes/flag.0rx"
  From PrimesDemo.run at line 49 column 5 of "example/primes/primes-demo.0rx"
  From main
ThreadCondition value originally created at:
  From ThreadCondition.new
  From ThreadFlag.new at line 7 column 5 of "example/primes/flag.0rx"
  From PrimesDemo.run at line 8 column 5 of "example/primes/primes-demo.0rx"
  From main
Aborted (core dumped)

The ThreadCondition in question is only used within ThreadFlag, and always with MutexLock.

The problem might be that the mutex needs to be locked before signaling the threads to continue.

ta0kira commented 3 years ago

I'm getting some other strange issues, e.g., an error in timedWait in PrimesDemo (which doesn't even call it), or getting a "not a Bool" error for the return value of a function that correctly returns Bool (verified in the generated C++.) This could be related to #163, like maybe the wrong functions are getting called.

ta0kira commented 3 years ago
example/primes/PrimesDemo: Failed condition: Bad ArgTuple index
  From ThreadCondition.timedWait
  From MutexLock.lock
  From ThreadFlag.getEnabled at line 33 column 7 of "example/primes/flag.0rx"
  From PrimesDemo.run at line 27 column 9 of "example/primes/primes-demo.0rx"
  From main

timedWait shouldn't be getting called. I really think this is a dispatching issue (#163).