mv iterator hot threads

Status

• merged to develop -
• code complete -
• development started - June 16, 2016

History / Context

This fix is independent of recent other iterator hang corrections. This fix deals with an iterator specific code within Basho's hot threads feature. The iterator specific code was only partial ported when the eleveldb hot threads code and leveldb hot threads code merged.

eleveldb's iterator objects, MoveItems, are reusable. MoveItems communicate the reuse desire to the hot threads logic via the resubmit() property. When resubmit() returns true, hot threads executes the same task again immediately. This is how eleveldb's iterators implement prefetch iterations (read of next iterator key/value in background while Erlang processes the current key/value).

Prior to merging eleveldb's hot threads with leveldb's hot threads, only eleveldb's code supported the resubmit() property. The support required an extra five lines of code within the thread loop routine. Unfortunately, leveldb had two thread loop routines. Only one of the two received the extra five lines during the merge. This branch adds the five lines supporting the resubmit() property to leveldb's second thread loop.

Branch Description

util/hot_threads.cc

Five code lines from HotThread::ThreadRoutine() now also exist in QueueThread::QueueThreadRoutine(). The block of code begins with "if (submission->resubmit())".

The long term problem is that these two thread routines exist in parallel to address a race condition. Proper defensive code would eliminate the need for such parallel routines. Item #2 in leveldb's github issue #181 addresses replacement logic that will possibly remove the need for the QueueThreadRoutine():

leveldb issue #181