Add support for real-time audio threads.

base/threading/platform_thread.h

 // Copyright (c) 2011 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.
 
 // WARNING: You should *NOT* be using this class directly.  PlatformThread is
 // the low-level platform-specific abstraction to the OS's threading interface.
 // You should instead be using a message-loop driven Thread, see thread.h.
 
 #ifndef BASE_THREADING_PLATFORM_THREAD_H_
 #define BASE_THREADING_PLATFORM_THREAD_H_
@@ skipping 29 matching lines @@
 const PlatformThreadHandle kNullThreadHandle = 0;
 #if defined(OS_MACOSX)
 typedef mach_port_t PlatformThreadId;
 #else  // OS_POSIX && !OS_MACOSX
 typedef pid_t PlatformThreadId;
 #endif
 #endif
 
 const PlatformThreadId kInvalidThreadId = 0;
 
+// Valid values for SetThreadPriority()
+enum ThreadPriority{
+  kThreadPriority_Normal,
+  // Suitable for low-latency, glitch-resistant audio.
+  kThreadPriority_RealtimeAudio

[darin (slow to review), 2011/05/13 17:51:12]

isn't it a bit unfortunate for base to have to know about the concept of
real-time audio???

isn't there maybe some better way to parameterize this so that a consumer could
use PlatformThread APIs to construct a thread suitable for real-time audio?

[scherkus (not reviewing), 2011/05/13 23:06:49]

I don't want to bikeshed this anymore, but what about Normal and High?

...and if setting between high/normal doesn't make sense you *could* go all the
way with just having a "IncreaseThreadPriority()" method

[Ken Russell (switch to Gerrit), 2011/05/13 23:11:01]

The Mac implementation is currently very specific to the audio use case, and I
can imagine wanting to have a high-priority enum that's different from the audio
enum. This was the motivation for suggesting the audio specific enum.

+};
+
 // A namespace for low-level thread functions.
 class BASE_API PlatformThread {
  public:
   // Implement this interface to run code on a background thread.  Your
   // ThreadMain method will be called on the newly created thread.
   class BASE_API Delegate {
    public:
     virtual ~Delegate() {}
     virtual void ThreadMain() = 0;
   };
@@ skipping 24 matching lines @@
   // CreateNonJoinable() does the same thing as Create() except the thread
   // cannot be Join()'d.  Therefore, it also does not output a
   // PlatformThreadHandle.
   static bool CreateNonJoinable(size_t stack_size, Delegate* delegate);
 
   // Joins with a thread created via the Create function.  This function blocks
   // the caller until the designated thread exits.  This will invalidate
   // |thread_handle|.
   static void Join(PlatformThreadHandle thread_handle);
 
+  static void SetThreadPriority(PlatformThreadHandle handle,

[scherkus (not reviewing), 2011/05/13 23:06:49]

could we get a comment + disclaimer here warning people not to carelessly bump
up the thread priority?

I think I linked you to the discussion before on chromium-dev:
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thre...

+                                ThreadPriority priority);
+
  private:
   DISALLOW_IMPLICIT_CONSTRUCTORS(PlatformThread);
 };
 
 }  // namespace base
 
 #endif  // BASE_THREADING_PLATFORM_THREAD_H_