Intermittently Failing Tests

[jdantonio]

I'm still trying to address all the intermittently failing tests. It's a Sisyphean task. Please use this thread to link to any failing Travis test runs that you believe are due to buggy tests.

[jdantonio]

• Concurrent::Agent behavior it should behave like observable first notification calls the #update method on all observers without a specified :func
• Concurrent::Event#reset does not interrupt waiting threads when event is unset
• Concurrent::SerializedExecutionDelegator it should behave like executor_service it should behave like global_thread_pool #post raises an exception if no block is given

[pitr-ch]

• Concurrent::TimerSet does not execute tasks early

[jdantonio]

• Concurrent::Event#reset does not interrupt waiting threads when event is unset
• Concurrent::SerializedExecutionDelegator it should behave like executor_service it should behave like global_thread_pool #post raises an exception if no block is given

[jdantonio]

• Concurrent::RubyFixedThreadPool it should behave like fixed_thread_pool overflow policy uses the calling thread for overflow under caller_runs

[jdantonio]

• Concurrent::RubyCachedThreadPool garbage collection removes from pool any thread that has been idle too long

[jdantonio]

• Concurrent::RubySingleThreadExecutor it should behave like executor_service #shutdown allows in-progress tasks to complete

[GrooveStomp]

I'm getting various failing specs, but I'm not sure how to evaluate them - ie., whether they're part of this intermittently failing specs bug or not.
Here's my most recent run of "rake": https://gist.github.com/GrooveStomp/d216376a7ecb191b807f

[jdantonio]

@GrooveStomp Those are tests that occasionally fail. They are very difficult features to test. Both myself and one other contributor have worked on those classes and tests and I believe the failure is with the tests, not the code. Would you mind reviewing the code being tested?

[jdantonio]

• Concurrent::RubyFixedThreadPool it should behave like fixed_thread_pool overflow policy raises an error when overflow on abort

[GrooveStomp]

@jdantonio Yes, certainly. Thanks.

[GrooveStomp]

@jdantonio I'm noticing that these issues present when running the full spec suite, but not nearly so much so (ie., not at all for me) when running individual spec files or specs. At first blush it seems like threads are being spawned and are still resident while subsequent specs run. Is there a brute-force way to wait for all threads to join before executing the next spec? I could try this locally and see how far it gets me.