Hi I've been thinking recently why are these two named like they are ... with a MS we're basically asking two questions: (1) should it block other merges from happening (or app thread from continuing) and (2) should it do its merges concurrently?
SMS answers 'true' to (1) and 'false' to (2), while CMS answers the opposite. BUT, there's really no reason why these two are coupled. E.g. someone who wants to block other merges from running, or hold the app thread until merges are finished, does not necessarily want the merges to run in sequence. Those are two different decisions. Even if you want to block the application thread and other merges, you can still benefit form having the merges run concurrently. So, I was thinking that what we really want is a BlockingMS and NonBlockingMS that can be used according to the answer you look for in (1), and then we can have variants for both that execute the merges concurrently or not. I think that serial merging should be supported w/ BlockingMS only, but am interested in other opinions. One of the scenarios for serial merging is if the application wants to ensure no additional threads are spawned other than what it decided to spawn, and therefore it can only be used w/ the BlockingMS.Another scenario is to control IO, but in this case a NonBlockingSerialMS may fit as well (depends if you think other merges may start while this one is running). In fact, w/o changing much, we can have CMS optionally block other merges / app thread by waiting until all merges are finished. We may even stick w/ the current SMS/CMS names, just documenting that CMS can be used to block threads, only merges will be done concurrently. What do you think? Shai
