kicad-developers team mailing list archive

["Torsten Hüter" <torstenhtr@xxxxxx>]

Hi Wayne,

this is of course right, but the idea would be to emulate cooperative multitasking with threads. This is done by synchronizing the threads with condition variables and mutexes. The principle can be found in the articles [1] or [2].

The idea is good, BUT after further research I'd say that there are two show stoppers:

(a) it's not recommended to use secondary threads to call GUI functions

http://docs.wxwidgets.org/trunk/overview_thread.html

(b) the OpenGL context is only valid for the current thread, it's required to change the context for every thread

https://www.opengl.org/wiki/OpenGL_and_multithreading

Ideally rendering and gui handling should happen only in the main thread; but that would be to restrictive for our purposes. 

This makes threads in my opinion unattractive for coroutines.

--

Yes, state machines or stackless coroutines are possible too, but then the tool-framework code has to be changed a lot. I'll evaluate the other options first. Setjmp/longjmp could work also, but here is stack handling the major issue.

Thanks,
Torsten


[1] Coroutines in C/C++: beyond Duff's Device, http://sjansen.blogspot.de/2008/04/coroutines-in-cc-beyond-duffs-device.html ;
[2] Cross-Platform Coroutines in C++, http://www.drdobbs.com/cpp/cross-platform-coroutines-in-c/184404529 ;
 

> Torsten,
>
> I've been thinking about your proposed changes and I'm not sure I'm
> comfortable making KiCad multi-threaded using a library such as pthreads
> or any other threading implementation. Context switching (cooperative
> multi-tasking) is bad enough but at least everything is happening in the
> same thread so no locking is required. Pre-emptive multi-tasking is
> much more difficult to deal with. Access to everything being touched by
> multiple threads has to be protected with locks which can make for some
> ugly code and debugging threaded applications can be difficult. What
> about using a state machine or some clever way to use events?

Wayne

On 1/6/2016 10:48 AM, Tomasz Wlostowski wrote:
> On 04.01.2016 15:07, Mark Roszko wrote:
>>> My offer would be to test an alternative implementation, to drop another Boost dependency and build upon a standard library foundation.
>>> pthreads is not standard library <.<
>>
>
> Hi Mark & Torsten,
>
> Feel free to test any implementation you like (personally I would try
> with setjmp() first). I don't have much time to work on this issue (I'm
> busy these days adding a reasonably fast wxDC support to the GAL canvas...).
>
> Cheers,
> Tom
>