kicad-developers team mailing list archive

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

Hi Chris,
 
please read the mail archive (Jan 2016), I've already tried this and experimented with different coroutine implementations. I've tested of course a variant based on pthreads too.
 
The major showstopper was, that's not recommended to use threads for GUI work, please read:
http://docs.wxwidgets.org/3.1/overview_thread.html
 
"[..] When writing a multi-threaded application, it is strongly recommended that no secondary threads call GUI functions. [..]"
 
This would be very restrictive and can't be guaranteed.
 
If you're still interested, I could upload this implementation on launchpad again. I've stopped working on this, because Tom proposed his libcontext and with the bugfixes it was working so far well on Windows.
 
--
 
In my opinion I'd drop coroutines entirely - they are nice if they're a build-in language concept (like Modula-2 coroutines), but C++ has not yet the best support for that. Alternatives are simple FSMs, sure that makes the code a bit bulkier, but would work on every machine without having to maintain assembler code.  The disadvantage is the work that you have to invest there (I have not much time to develop KiCad code anymore).
 
Thanks,
Torsten

Sorry for the double post, forgotten to switch to plain text.
 
>> My point is that threading could be used to implement a *drop-in
>> replacement*...not that the tool framework should be structured around
>> them, but that it continues to use coroutines, and we make a coroutine
>> library that is implemented using threads... :P