until the server is done handling its request.
In most tests, this is handled automatically because the client expects
a reply from the server, and waits for this reply. This test is
different because the server does handle the message, but does not send
a reply, so the client does not wait for one. When the child process
exits before the parent has had a chance to inspect the message it
received, the parent will find a dead name where it expects the remote
port to be, causing this test to be flaky based on the outcome of this
race.
The potential for a similar race existed in the
MachMessageServer.ComplexNotDestroyedNoReply test because it also
involved a request without a reply. In that test, the situation was
handled by not allowing the child to exit until signaled to do so by the
parent. The same logic should be used for both no-reply tests.
TEST=util_test MachMessageServer.ReturnCodeNoReply
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/569953002
There’s no reason that “in” or “request” messages should be non-const.
This makes them const, bridges the const gap left by the MIG-generated
“check” functions with wrappers, and uses non-const fields in
“out” messages instead of const fields in “in” messages for in-out
parameters.
TEST=util_test ExcServerVariants.*:MachMessageServer.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/564533002
(MACH_RCV_LARGE).
This also adds a COMPILE_ASSERT to check that the
PersistentNonblockingFourMessages test case is not exceeding the value
of MACH_PORT_QLIMIT_DEFAULT.
TEST=util_test MachMessageServer.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/557793002
MachMessageServer is much like mach_msg_server() and
mach_msg_server_once(), but with a C++ interface and with a number of
deficiencies corrected.
TEST=util_test MachMessageServer.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/544393002
