Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
drop coprocess programming model #1081
Since I think we're now "all in" with the future/continuation model of concurrency in reactor programming, and the coprocess handle mode was only used in tests (and in a convoluted way at that), this PR reworks those tests and drops coprocess support.
The immediate benefit is that the message dispatch code is simplified. But the reworked tests are now also more serviceable.
The RPC tests, which are meant to be unit tests run before the the broker is tested, used a loop connector and the FLUX_O_COPROC flag to simulate a server thread. The replacement method is a simple modification to the shmem connector that allows two flux_t handles to be set up back-to-back. Instead of running rpcs and service methods in the same thread, the tests now run service methods in a separate thread. The code for setting up the test, which is reminiscent of czmq's zactor class, is abstracted in t/rpc/util.[ch], and was not dignified with a place in the Flux API since back to back flux_t handles is a pretty weird construct.
While removing the specialized coproc dispatcher, I got rid of the deferred message handler deletion code that @grondo recently noted was unnecessary since zlist_remove is safe during a list walk.
Finally, I hit bug #1063 a few times running make check on cloud9 so I included a fix for that.
@@ Coverage Diff @@ ## master #1081 +/- ## ========================================== + Coverage 77.94% 78.03% +0.08% ========================================== Files 151 150 -1 Lines 26123 25954 -169 ========================================== - Hits 20362 20252 -110 + Misses 5761 5702 -59