Hi Brett, On Tue, Nov 18, 2008 at 2:27 PM, Brett Wilson <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: > > > Thanks for your input, I think I understand now. Both the Windows > message > > loop and the chrome task queue co-exist in the MessageLoop class via > > Delegate and Dispatcher implementations. Chrome uses the Windows message > > loop as a means for managing the task queue (via WM_TIMER calls), so > there > > should be no need for me to post Windows messages directly to the UI > > thread. Instead, to call a Browser object method (like GoBack()) from a > > separate thread I should execute MessageLoopForUI::current()->PostTask() > > (which is itself thread-safe) to have the UI thread execute a method that > I > > provide, which would in turn make the Browser method call. > > Kind of. MessageLoopForUI doesn't give ui the UI message loop. It > gives you the current message loop assuming that it's a UI "type" of > loop. You'll have to track independently which message loop the UI > message loop is. We usually pass this information into the objects > that live on the secondary threads when they start. Am I correct in thinking that there's only one UI message loop per process (created in BrowserMain())? If so, I'd be curious to know why a pointer to the UI message loop isn't available from the global BrowserProcess instance. > > > Brett Thanks, Marshall > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
