I have a GUI project (Tk), which makes use of threads for performing
background filesystem searches based on a filename pattern.
My system is a 4 cores, on recent Linux; the interpreter is MRI 2.3.
At any given time, there should be at most one search background
thread, so the requests for new searches cause termination of the one
The search code is properly structured: it's a simple loop through
directories, that exits either when the directories are exhausted, or
when a termination flag is passed (by the project scheduler) to the
The problem I've observed is that search threads take at least 100ms
before terminating, so that when searches come in in quick succession,
they start to pile up.
I've had a look at the source code, and I have the suspicion that this
is related to `TIME_QUANTUM_USEC`. In the 2.1 changelog, `When running
on uniprocessor systems, every th.kill needs TIME_QUANTUM_USEC time`
is mentioned (I'm not sure if "processor" refers to CPU or core).
I've tried a very simplified version of the project, and on
JRuby/Rubinius the time slice is significantly smaller (at least one
order of magnitude smaller).
Is this behavior expected, or I'm unintentionally causing it? In the
latter case, which conditions could potentially cause it?