Hi Chris,
please read the mail archive (Jan 2016), I've already tried this and experimented with different coroutine implementations.
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.
An alternative 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 anymore to develop KiCad code).
Thanks,
Torsten
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
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
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
