Re: [wxlua-users] wxLua dispatching Asynchronous events?

[Javier Mr <jav...@ym...>]

Hi, 


thanks a lot for the detailed information. I finally resolve the issue and it turns out that was due to running my App compiled in Debug and loading wxLua, in release. Once done that the app works perfectly.

The problem was that it didn't crash at start or always at the same point, mostly crashed when extresed. But i have said, problem running with Debug and Release libraries mixed.

Best regards.
Javi



----- Mensaje original -----
> De: John Labenski <jla...@gm...>
> Para: Javier Mr <jav...@ym...>; wxl...@li...
> CC: 
> Enviado: Viernes 12 de abril de 2013 23:56
> Asunto: Re: [wxlua-users] wxLua dispatching Asynchronous events?
> 
> On Fri, Apr 12, 2013 at 4:13 PM, Javier Mr <jav...@ym...> 
> wrote:
>>  Hi,
>> 
>>  i'm using wxLua to make an interface, but i'm facing several 
> crashed and after looking for the source of them i could find it. I have an idea 
> of a posible reason so i will ask in case this is a known behaviour. First 
> several questions?
>> 
>>  1. First in wxWidgets, are events (click, cell changes, tree item 
> activation, etc...) dispatched synchronously or asynchronously?
> 
> Asynchronously (in a way), but single threaded. wxWidgets apps
> basically "hang" in the native OS event loop until the mouse is moved,
> key pressed, etc. You can "pump" the event loop by requesting a
> wxIdleEvent or using a wxTimer.
> 
>>  2. If asynchronously, could it be posible that to events are dispatcher 
> against the same lua state simultaneaously?.
> 
> You will never have two functions called at once by the wxWidgets event loop.
> 
>>  What i have is a tree control with several items and a grid, so when a item 
> in the tree is activated the grid is filled up. I'm currently connected to 
> events for tree item activation, tree item right click, grid cell changed.
>> 
>>  Let's suppose the wxWidget thread running on the main loop is A ( 3. 
> which i belive is the thread that load the lua script, isn't it? ),
> 
> Yes, same thread.
> 
>>  when i activate a tree node a event (evt1) will be queued in the event 
> queue (4. isn't it?), and the main loop will check for pending events it 
> will find the event (evt1) and will dispatch it (5. but will the lua function 
> from the event handler be called by the thread running the main loop (A) or will 
> a second thread be created (B) ?).
>> 
> 
> Never a second thread.
> 
>> 
>>  In case question 5 is that a new thread will be created for executing the 
> handler, could another event in the tree (evt2) be queued in the events queue 
> and then the main loop thread (A) dispatch it creating a new thread (C) 
> **accesing** and modifiying the lua state while the previous event thread (B) 
> hasn't return yet?
>> 
> 
> Nobody, including your code, should *ever* try to access any wxWidgets
> control from any other thread than the one it was created in.
> 
>>  My hole test so far have been repainting the grid while clicking several 
> timer over a tree item so the event handler doesn't return inmediatly.
>> 
>>  I think all previous questions could be summariazed but, does wxLua protect 
> the access to the lua state from within wxLua?
> 
> No, there would be way too many places to put mutexes, it would be really ugly.
> 
> A wxLua app works this way.
> 
> 1) Start Lua... load the libs require("wx") etc.
> 2) Execute the Lua code, but it quickly gets to the end of the code.
>     The code defines functions, creates the wxFrame add child windows,
> connect events... but doesn't really do any "work"
> 3) Then if any wxFrames (or any wxTopLevelWindow derived class) exist,
> wxLua starts the wxWidgets event loop and the app "hangs" in it
> waiting for user input.
> 
> Hope this makes sense,
>      John
>