RE: Multithreading, callbacks from unknown threads

["Thijs Schreijer" <thijs@...>]

> even on localhost, using UDP for messaging has a perceptible overhead.
I'm aware of that, but for my use its network centric, so 1 additional UDP packet won't be my biggest performance issue.

>  feel free to steal code from my helper threads toolkit [1] where it
> handles a thread pool in C with a single Lua space by using FIFO
> queues.

If I'm correct reading the docs, the helper threads toolkit manages its own thread pool to process tasks. The case I'm referring to is the same as the one from Michal Kottman's initial email (9-mar-2012);
> However, things changed in Qt 4.8 - even though the 'qtcore' and 
> 'qtgui' modules still function as expected (at least what I 
> experimented with), the 'qtwebkit' module seems to create new 
> thread(s) for downloading/rendering etc.
>
> The problem is that lqt generates "shell" classes for every Qt 
> class containing virtual methods in order to allow their 
> (re)implementation in Lua. This means that the background threads 
> eventually end in Lua, and sooner or later, cause a segfault.

The library gets started, and creates its own threadpool, so not controllable from my code/the Lua state, and then calls a callback using one of those workerthreads.
Also in this case, qtwebkit downloading and rendering, then 1 additional udp packet shouldn't result in a performance issue.
Unless the helper threads kit provides a way around this?

Thijs