Web MIDI: fix multi-threading problem around message buffer handling

content/common/media/midi_messages.h

 // Copyright (c) 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // IPC messages for access to MIDI hardware.
 // Multiply-included message file, hence no include guard.
 
 #include "base/basictypes.h"
 #include "content/common/content_export.h"
 #include "ipc/ipc_message_macros.h"
@@ skipping 25 matching lines @@
                     int /* client id */,
                     bool /* success */)
 
 // Messages for IPC between MIDIMessageFilter and MIDIHost.
 
 // Renderer request to browser for access to MIDI services.
 IPC_MESSAGE_CONTROL1(MIDIHostMsg_StartSession,
                      int /* client id */)
 
 IPC_MESSAGE_CONTROL3(MIDIHostMsg_SendData,
-                     int /* port */,
+                     unsigned int /* port */,

[scherkus (not reviewing), 2013/08/21 17:46:29]

I believe this should be uint32

http://dev.chromium.org/developers/coding-style#TOC-Types

[Takashi Toyoshima, 2013/08/22 05:47:45]

Done.

                      std::vector<uint8> /* data */,
                      double /* timestamp */)
 
 // Messages sent from the browser to the renderer.
 
 IPC_MESSAGE_CONTROL4(MIDIMsg_SessionStarted,
                      int /* client id */,
                      bool /* success */,
                      media::MIDIPortInfoList /* input ports */,
                      media::MIDIPortInfoList /* output ports */)
 
 IPC_MESSAGE_CONTROL3(MIDIMsg_DataReceived,
                      int /* port */,
                      std::vector<uint8> /* data */,
                      double /* timestamp */)
 
 IPC_MESSAGE_CONTROL1(MIDIMsg_AcknowledgeSentData,
                      size_t /* bytes sent */)

[scherkus (not reviewing), 2013/08/21 17:46:29]

shouldn't this also be an explicitly sized type?

I thought size_t was to be avoided in IPC messages

[Takashi Toyoshima, 2013/08/22 05:47:45]

I see. A lot of messages which handles size seem to use uint32 instead of
size_t.
I'll use uint32 here.

[palmer, 2013/08/22 18:25:41]

Yes, scherkus is correct that size_t, like all relatively-sized int types, is
not good in IPC.

The reason is that, although size_t is the correct type for sizes, IPC can span
processes built with different processor models (e.g. a 64-bit browser, where
size_t is 64 bits, talking to a 32-bit plugin, where size_t is 32 bits).

Use an unsigned, explicitly-sized type that is wide enough to handle the range
of values you expect. And if you find yourself casting it to size_t, which is
likely, make sure that the value does not get truncated. E.g. a uint64_t will
get truncated when cast to size_t in a 32-bit process. (But conversely, a
uint32_t will cast up to a 64-bit process' size_t just fine.)

So, yeah, uint32_t will work. :)