wxEventLoop

[Robert Kubrick]

I have to write a wxWidgets program to process real-time data from a  
network connection. Because of the large number and frequency of  
messages (several hundred updates per second) the multi-threaded  
approach doesn't seem right to me. I think a better approach is to  
test the socket channel descriptor and process GUI events all in the  
same main loop.

I'm not clear what should be done to add more network events. Should  
I redefine both wxApp::MainLoop() and wxEventLoop::Run()?

int wxAppBase::MainLoop()
{
     wxEventLoopTiedPtr mainLoop(&m_mainLoop, new wxEventLoop);

     return m_mainLoop->Run();
}

Or is it better to redefine OnNextIteration()? According this thread  
this is not going to work on GTK: http://thread.gmane.org/ 
gmane.comp.lib.wxwidgets.devel/96346
_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Vadim Zeitlin-4]

On Sat, 6 Sep 2008 22:12:29 -0400 Robert Kubrick <robertkubrick@...> wrote:

RK> I have to write a wxWidgets program to process real-time data from a  
RK> network connection. Because of the large number and frequency of  
RK> messages (several hundred updates per second) the multi-threaded  
RK> approach doesn't seem right to me.

 FWIW I have a completely opposite feeling. I'd say that you really need to
run a (possibly high priority) thread to deal with it.

RK> I think a better approach is to  test the socket channel descriptor and
RK> process GUI events all in the  same main loop.

 There is no clean way to do this with wx 2.8 unfortunately. We will have
it in wx 3.0 but I still didn't find tome to implement it so far
unfortunately... In any case, in 2.8 there is no efficient way to handle
another events source at the event loop level so you should really use a
thread. Or switch to svn trunk and help us developing it there ;-)

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/


_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Robert Kubrick]

On Sep 8, 2008, at 4:38 PM, Vadim Zeitlin wrote:

> On Sat, 6 Sep 2008 22:12:29 -0400 Robert Kubrick  
> <robertkubrick@...> wrote:
>
> RK> I have to write a wxWidgets program to process real-time data  
> from a
> RK> network connection. Because of the large number and frequency of
> RK> messages (several hundred updates per second) the multi-threaded
> RK> approach doesn't seem right to me.
>
>  FWIW I have a completely opposite feeling. I'd say that you really  
> need to
> run a (possibly high priority) thread to deal with it.
>
> RK> I think a better approach is to  test the socket channel  
> descriptor and
> RK> process GUI events all in the  same main loop.
>
>  There is no clean way to do this with wx 2.8 unfortunately. We  
> will have
> it in wx 3.0 but I still didn't find tome to implement it so far
> unfortunately... In any case, in 2.8 there is no efficient way to  
> handle
> another events source at the event loop level so you should really  
> use a
> thread. Or switch to svn trunk and help us developing it there ;-)

Thanks. A third approach is to install an Idle event handler and  
check the socket from there. For now I'll use this method and switch  
to MT if I see that the GUI can't follow. I'm concerned about the  
event overhead in wxWidgets: one event per message (a few hundred  
events per second) sounds like a lot of mutex lock/unlock and stack  
work.

For reference I'm adding some links to a few resources on main loop  
overriding:
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/96346/focus=96358
http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45505
http://www.irrlicht3d.org/pivot/entry.php?id=347
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/37301

>
>  Regards,
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
>                http://www.tt-solutions.com/
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Vadim Zeitlin-4]

On Mon, 8 Sep 2008 16:55:24 -0400 Robert Kubrick <robertkubrick@...> wrote:

RK> A third approach is to install an Idle event handler and  
RK> check the socket from there.

 Yes, this is simple but it's polling and is hardly efficient.

RK> I see that the GUI can't follow. I'm concerned about the  event
RK> overhead in wxWidgets: one event per message (a few hundred  events per
RK> second) sounds like a lot of mutex lock/unlock and stack  work.

 I don't think it's going to be too bad but even if it is, what's wrong
with pooling messages and sending one event per 10 (or 100, or ...)
messages?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/


_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Robert Kubrick]

On Sep 8, 2008, at 5:24 PM, Vadim Zeitlin wrote:

> On Mon, 8 Sep 2008 16:55:24 -0400 Robert Kubrick  
> <robertkubrick@...> wrote:
>
> RK> A third approach is to install an Idle event handler and
> RK> check the socket from there.
>
>  Yes, this is simple but it's polling and is hardly efficient.
>
> RK> I see that the GUI can't follow. I'm concerned about the  event
> RK> overhead in wxWidgets: one event per message (a few hundred  
> events per
> RK> second) sounds like a lot of mutex lock/unlock and stack  work.
>
>  I don't think it's going to be too bad but even if it is, what's  
> wrong
> with pooling messages and sending one event per 10 (or 100, or ...)
> messages?

It would reduce the load on the wxWidgets event handling system, but  
I still would have to lock the memory where messages are stored. At  
the end it's almost like serializing the two threads: thread 2 reads  
10 messages, then thread 1 does the GUI work, then thread 2 can store  
another 10 messages...
Doesn't this come back to an idle procedure?

>
>  Regards,
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
>                http://www.tt-solutions.com/
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Vadim Zeitlin-4]

On Mon, 8 Sep 2008 18:02:41 -0400 Robert Kubrick <robertkubrick@...> wrote:

RK> It would reduce the load on the wxWidgets event handling system, but  
RK> I still would have to lock the memory where messages are stored. At  
RK> the end it's almost like serializing the two threads: thread 2 reads  
RK> 10 messages, then thread 1 does the GUI work, then thread 2 can store  
RK> another 10 messages...
RK> Doesn't this come back to an idle procedure?

 I guess it does if you're really doing nothing else than processing these
messages. However another thread won't be blocked by anything the GUI does
and so it can continue accumulating the messages even when the GUI is busy.
And if you ever have fewer messages your program won't be uselessly
consuming 100% of the CPU unlike the EVT_IDLE-based approach.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/


_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Robert Kubrick]

On Sep 9, 2008, at 8:43 AM, Vadim Zeitlin wrote:

> On Mon, 8 Sep 2008 18:02:41 -0400 Robert Kubrick  
> <robertkubrick@...> wrote:
>
> RK> It would reduce the load on the wxWidgets event handling  
> system, but
> RK> I still would have to lock the memory where messages are  
> stored. At
> RK> the end it's almost like serializing the two threads: thread 2  
> reads
> RK> 10 messages, then thread 1 does the GUI work, then thread 2 can  
> store
> RK> another 10 messages...
> RK> Doesn't this come back to an idle procedure?
>
>  I guess it does if you're really doing nothing else than  
> processing these
> messages. However another thread won't be blocked by anything the  
> GUI does
> and so it can continue accumulating the messages even when the GUI  
> is busy.

Correct, I should have provided more background. In my case the whole  
application is finalized to display data on a spreadsheet, so there  
isn't much else going on other than Grid updates. The GridTable must  
be synchronized for access from the two threads. But if you have a  
heavily interactive GUI, then it probably makes a huge difference to  
have two threads working, PROVIDED you have at least two cores  
available. I am not convinced you can have a large benefit on a  
single core system.

> And if you ever have fewer messages your program won't be uselessly
> consuming 100% of the CPU unlike the EVT_IDLE-based approach.

Yes. Then again, the idle proc could yield CPU time after a few calls  
where the socket did not receive any message. But in general I  
noticed that if you call event.RequestForMore() the program spins in  
the idle proc a lot.

>
>  Regards,
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
>                http://www.tt-solutions.com/
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

_______________________________________________
wx-users mailing list
wx-users@...
http://lists.wxwidgets.org/mailman/listinfo/wx-users