Mark McLoughlin wrote:
> On Tue, 2009-07-21 at 21:20 -0500, Anthony Liguori wrote:
>> Mark McLoughlin wrote:
>>> My take on it is that we're all agreed that it's never valid with the
>>> current monitor protocol for a client to queue up multiple fds. It's a
>>> synchronous protocol, you can't send multiple commands at once.
>>>   
>> I think there's a subtle point that was lost in the thread.  While we'll 
>> only need to queue one fd per MonitorState, we'll still need to deal 
>> with multiple fds per CharDriverState.
> 
> Why? For a theoretical use case, or for the current monitor interface?
> 

There can be multiple monitors attached at the same time, already today.

> If the latter, then I don't follow.
> 
> The flow is as follows:
> 
>   client                     server
>   ------                     ------
>   send request ->
>   wait for response          
>                              read request
>                              process msgfd, allowing only a single fd
>                              monitor handles request
>                           <- send reply
>   handle response            close msgfd if unused
>   send next request ->
> 
> If the client sends multiple requests at once, it is broken - it must
> wait for a "(qemu) " reply before sending another request.
> 
> If the client sends multiple fds in a single request, it is broken - no
> monitor commands support multiple fds.
> 
> If the client is broken and sends multiple fds, we only read the first
> one and the kernel frees the others.
> 
> If the client sends an fd along with a request which does not require an
> fd, we just close that fd after we've processed the request.
> 
> If we get a new protocol which allows multiple requests per message or
> multiple fds per request, we can easily add a queue then.
> 
> Cheers,
> Mark.
> 

Jan