Using lqt with Lua Lanes

[Michael Kirsch]

I have some Lua code using a select-based event loop, and I would like
to run it in a separate Lane in an lqt application. The problem is how
can I queue events in the event loops from the other Lane?

Yes, this question isn't entirely lqt-related, but I don't see any
place for asking questions about Lanes. And only knowing how to queue
events in the Qt event loop from the other thread would still be
helpful.

[Michal Kottman]

Currently lqt does not work well with threads - I'm having problems with upgrading Qt 4.8. Threads + lqt should be considered "here there be dragons". It will most likely not work out of the box.

Maybe you should start experimenting with QCoreApplication::postEvent(), because it is thread safe, however I cannot assure that the binding will co-operate nicely. To be honest, I haven't experimented with having lqt loaded in multiple lanes, maybe it will work, because they are essentially different states.

I imagine you could somehow work around this problem by using lindas provided by lanes for communication, and re-creating the events in a single thread.

[Michael Kirsch]

On Apr 13, 1:21 pm, Michal Kottman <k0mpju...@gmail.com> wrote:

> Maybe you should start experimenting with QCoreApplication::postEvent(),
> because it is thread safe, however I cannot assure that the binding will
> co-operate nicely. To be honest, I haven't experimented with having lqt
> loaded in multiple lanes, maybe it will work, because they are essentially
> different states.

I'm talking about calling a slot, not sending a QEvent. Any similar
function to do that?

> I imagine you could somehow work around this problem by using lindas
> provided by lanes for communication, and re-creating the events in a single
> thread.

I'm not sure what you mean. How do you wait for lindas and run the Qt
event loop at the same time?

[Michael Kirsch]

I figured out a solution using sockets to communicate between the
threads (using a LuaSockets socket in the worker thread and a
QTcpSocket in the GUI thread). To connect them, I created a QTcpServer
in the GUI thread to accept the connection. The problem is that it
segfaults when I call the listen() method:

win._evsocket = QTcpServer.new(win)
win._evsocket:connect('2newConnection()', win,
'1_on_evsocket_connected()')
win._evsocket:listen() -- segmentation fault here

Is this a bug in lqt, or am I doing somethong wrong?

[Michal Kottman]

On 18 April 2012 16:04, Michael Kirsch <mkirs...@gmail.com> wrote:

I figured out a solution using sockets to communicate between the
threads (using a LuaSockets socket in the worker thread and a
QTcpSocket in the GUI thread). To connect them, I created a QTcpServer
in the GUI thread to accept the connection. The problem is that it
segfaults when I call the listen() method:

   win._evsocket = QTcpServer.new(win)
   win._evsocket:connect('2newConnection()', win,
'1_on_evsocket_connected()')
   win._evsocket:listen() -- segmentation fault here

Is this a bug in lqt, or am I doing somethong wrong?

I am able to run the following code just fine:

    local s = QTcpServer()

    s:connect('2newConnection()', function(...) print(...) end)

    s:listen()

 Could you try to get a debug traceback of the segfault? 

[Michael Kirsch]

On Apr 18, 10:46 am, Michal Kottman <k0mpju...@gmail.com> wrote:
> I am able to run the following code just fine:
>
>     local s = QTcpServer()
>     s:connect('2newConnection()', function(...) print(...) end)
>     s:listen()
>
>  Could you try to get a debug traceback of the segfault?

It doesn't print a traceback.

[Michal Kottman]

Yes, it does not, try running your application under gdb:

$ gdb --args lua myapplication.lua

....

(gdb) r

When the application crashes, go back to gdb and type the following:

(gdb) bt full

[Michael Kirsch]

On Apr 18, 12:05 pm, Michal Kottman <k0mpju...@gmail.com> wrote:
> try running your application under gdb:
>
> $ gdb --args lua myapplication.lua
> ....
> (gdb) r
>
> When the application crashes, go back to gdb and type the following:
>
> (gdb) bt full

This is what happens:

% gdb --args lua main.lua
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/
licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/lua...(no debugging symbols
found)...done.
(gdb) run
Starting program: /usr/bin/lua main.lua
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Cannot find new threads: generic error
(gdb) bt
Target is executing.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/lua main.lua
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Cannot find new threads: generic error
(gdb) quit
A debugging session is active.

Inferior 1 [process 20301] will be killed.

Quit anyway? (y or n) y

[Michal Kottman]

On 18 April 2012 18:12, Michael Kirsch <mkirs...@gmail.com> wrote:

This is what happens:

... 

   Cannot find new threads: generic error

Oh right, the dreaded "cannot find new threads: generic error"... What operating system are you running under?

The problem is that gdb only supports multithreaded applications if the application itself links to pthreads. This is not the case for Lua, so gdb does not start monitoring new threads, and then Qt comes in as a module and starts spawning threads.

I solved this issue by force-linking the lua executable to pthreads. I just added -pthread after -lreadline in the Lua makefile for my system. Gdb then happily starts with threading support.

[Michael Kirsch]

On Apr 18, 12:40 pm, Michal Kottman <k0mpju...@gmail.com> wrote:
> Oh right, the dreaded "cannot find new threads: generic error"... What
> operating system are you running under?

64-bit Arch Linux

> The problem is that gdb only supports multithreaded applications if the
> application itself links to pthreads. This is not the case for Lua, so gdb
> does not start monitoring new threads, and then Qt comes in as a module and
> starts spawning threads.

I'm only creating threads with Lanes (unless Qt starts threads
internally when you use sockets?).

> I solved this issue by force-linking the lua executable to pthreads. I just
> added -pthread after -lreadline in the Lua makefile for my system. Gdb then
> happily starts with threading support.

I'll try compiling Lua that way and will post the results.

[Michael Kirsch]

Here is the backtrace:

#0 0x00007ffff27a4677 in QHostAddress::protocol() const () from /usr/
lib/libQtNetwork.so.4
#1 0x00007ffff27c9613 in QTcpServer::listen(QHostAddress const&,
unsigned short) () from /usr/lib/libQtNetwork.so.4
#2 0x00007fffebd7552d in lqt_bind_23866(lua_State*) () from /usr/lib/
lua/5.1/qtnetwork.so
#3 0x00007fffebd75b8c in lqt_dispatcher_listen_23862(lua_State*) ()
from /usr/lib/lua/5.1/qtnetwork.so
#4 0x0000000000408004 in luaD_precall ()
#5 0x0000000000411348 in luaV_execute ()
#6 0x000000000040845d in luaD_call ()
#7 0x00000000004076da in luaD_rawrunprotected ()
#8 0x00000000004085ef in luaD_pcall ()
#9 0x0000000000405d0f in lua_pcall ()
#10 0x0000000000403e46 in docall ()
#11 0x00000000004047d6 in pmain ()
#12 0x0000000000408004 in luaD_precall ()
#13 0x0000000000408414 in luaD_call ()
#14 0x00000000004076da in luaD_rawrunprotected ()
#15 0x00000000004085ef in luaD_pcall ()
#16 0x0000000000405d85 in lua_cpcall ()
#17 0x0000000000403a74 in main ()

[Michael Kirsch]

I found that explicitly specifying the arguents (instead of relying on
the defaults) fixed the segfault issue:

win._evsocket:listen(QHostAddress(), 0)

I guess that this must be an lqt bug, then.