![]() The problem is that multiMessage has changed the semantics of the replyHandler block multiMessage 's replyHandler block takes a reference on the reply object and overwrites the input message object in the sub_messages array: Why would you invoke a block called replyHandler if you had no reply to send? And that means that they don't invoke the replyHandler block. Since they don't return a value, they don't send a reply message. Think of them like void functions in C they have no return value. However not all of the message types expect to send a reply. For example, message type 3 is handled by handleFlushManagedMessage, which invokes the replyHandler block to return a reply. If we imagine that there is no multiMessage, then the semantics of the replyHandler block which gets passed to each message handler are: " invoke me to send a reply ". ![]() When all the sub-messages have been processed they create an xpc_array from all the replies and invoke the replyHandler passed to this function passing a reply message containing an xpc_array of sub-message replies. It pulls each of them out of the input xpc_array with xpc_array_get_value and passes them to the handleMessage method but with a different replyHandler block which, rather than immediately sending the reply message back to the client, instead overwrites the input sub-message pointer in the sub_messages array with the reply. The multiMessage handler is expecting the input message to be an xpc_array of xpc_dictionary objects, which would be the sub-messages to process. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |