• There was a discussion starting here: julep: a @select statement JuliaLang/julia#13763 (comment) that there is a race-condition for edge-triggered events in this implementation that can cause events to be dropped. We should consider whether it's possible to fix this, or if we should simply drop support for Condition variables.

• (Fixed in Support Threads.Condition variables in Select. #3) There is another problem that I noticed, which is that the current implementation of @select leads to concurrency violations for multithreaded Thread.Conditions, because the wait(::Thread.Condition) occurs on a different task than the user's original lock(::Thread.Condition), so the unlock fails. It's the same as this MWE:

  julia> c = Threads.Condition();
  
  julia> lock(c)
  
  julia> Threads.@spawn wait(c)
  Task (failed) @0x000000011f3bad10
  unlock from wrong thread
  error(::String) at ./error.jl:33
  unlockall(::ReentrantLock) at ./lock.jl:121
  wait(::Base.GenericCondition{ReentrantLock}) at ./condition.jl:105
  (::var"##17#18")() at ./threadingconstructs.jl:113

For the second issue above (wait occurs on a different Task), maybe there is some way to implement a custom wait() function that unlocks the parent thread? This needs to be investigated.