As an intermediary step towards having a message pump handling IO through com...

As an intermediate step towards having a message pump handling IO through completion ports, this CL creates two types of message pumps for windows: one to handle UI threads and another one to handle IO threads.

I'm basically moving stuff around, except by the fact that now UI threads will not process APCs or wait on objects (those things only happen on message loops of TYPE_IO)


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=2602

[darin (slow to review), 2008-09-24 20:19:05]

We could obviously strip the MessagePumpForIO down much further, eliminating the
need for it to mess with HWNDs or MSGs.  However, that is probably not worth the
time since we are anyways trying to change it all over to use an IO completion
port.

http://codereview.chromium.org/3094/diff/1/4
File base/message_loop.cc (right):

http://codereview.chromium.org/3094/diff/1/4#newcode74
Line 74: #if defined(OS_WIN)
we should have a TODO about breaking this out of the #ifdef

http://codereview.chromium.org/3094/diff/1/2
File base/message_loop.h (right):

http://codereview.chromium.org/3094/diff/1/2#newcode455
Line 455: base::MessagePumpForIO* pump_io() {
it seems like there should be a TODO to move this out of the #if defined(OS_WIN)

also perhaps pump_win() should be changed to pump_ui() and moved to
MessageLoopForUI in a similar manner.  that would at least be more consistent. 
i realize that MessageLoop currently uses pump_win(), but that could reasonably
change to static_cast<MessageLoopForUI*>(this)->pump_ui()

http://codereview.chromium.org/3094/diff/1/5
File base/message_pump_win.h (right):

http://codereview.chromium.org/3094/diff/1/5#newcode142
Line 142: virtual void DoRunLoop() = NULL;
nit: should be "= 0" per the style guide

[rvargas (doing something else), 2008-09-25 02:30:56]

Thanks,

Yes, there is a lot of things to remove from the MessagePumpForXX once we have
them working separated.

I uploaded a new version, please take another look. I think it's better to keep
pump_win and avoid casts going from MessagePumpForIO to MessagePumpForUI, but we
can probably reconsider that after removing all the methods that should not be
part of each type of message pump. I added pump_ui for symmetry though.

On 2008/09/24 20:19:05, Darin Fisher (Google) wrote:
> We could obviously strip the MessagePumpForIO down much further, eliminating
the
> need for it to mess with HWNDs or MSGs.  However, that is probably not worth
the
> time since we are anyways trying to change it all over to use an IO completion
> port.
> 
> http://codereview.chromium.org/3094/diff/1/4
> File base/message_loop.cc (right):
> 
> http://codereview.chromium.org/3094/diff/1/4#newcode74
> Line 74: #if defined(OS_WIN)
> we should have a TODO about breaking this out of the #ifdef
> 
> http://codereview.chromium.org/3094/diff/1/2
> File base/message_loop.h (right):
> 
> http://codereview.chromium.org/3094/diff/1/2#newcode455
> Line 455: base::MessagePumpForIO* pump_io() {
> it seems like there should be a TODO to move this out of the #if
defined(OS_WIN)
> 
> also perhaps pump_win() should be changed to pump_ui() and moved to
> MessageLoopForUI in a similar manner.  that would at least be more consistent.

> i realize that MessageLoop currently uses pump_win(), but that could
reasonably
> change to static_cast<MessageLoopForUI*>(this)->pump_ui()
> 
> http://codereview.chromium.org/3094/diff/1/5
> File base/message_pump_win.h (right):
> 
> http://codereview.chromium.org/3094/diff/1/5#newcode142
> Line 142: virtual void DoRunLoop() = NULL;
> nit: should be "= 0" per the style guide

[darin (slow to review), 2008-09-25 05:53:51]

OK, LGTM