kicad-developers team mailing list archive

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

Hi Tom,
 
thanks for your point of view - I'm guessing I've missed that you're working already on your variant of boost::context. This is of course a feasible way. I'm not the biggest fan of that either, because the (low level) assembler code has to be maintained, tested on all platforms, but as long as you can guarantee that it works always, it should be good.
 
I've reviewed also the tool code and I've found there not such a huge demand to have coroutines, they're "nice to have".
 
--
 
I've used protothreads for some embedded projects, you're right they look "uglier" and are sometimes a bit tricky - but easier than state machines to write. The Contiki OS is based on them. The comment about the stability was related to the implementation of the coroutine itself and is a *subjective impression*, it's of course true that it can't prevent a segfault somewhere else.
 
--
 
I can of course test your code, I'll use the "stress test" for that :):)
 
Thanks,
Torsten
 

Many thanks for your work. I'm not particularly thrilled about stackless
coroutines for the reasons below:
- They would require a major rewrite of the tool code. If we were to
rewrite it, I'd rather drop coroutines completely.
- Performance is not an issue. The tools just handle UI events.
protothreads library was invented for asynchronous I/O, where
performance is critical. In Kicad, coroutines overhead is minimal.
- They are based on macros, which not only means strange-looking (not to
say ugly) code, but is also hard to debug.
- I can't agree that if something goes wrong, the stackless coroutine
will just exit, but a stackful one will crash. If there's a segfault,
you'll get a crash independently of the coroutine implementation.

Back to the original issue: Boost::context stopped working on MSYS2. The
reason is Boost developers don't want to use GNU assembler on Windows,
and the GNU asm port of the context switching functions is not the same
as the MASM one (since the authors have changed the context ABI at some
point). We shouldn't play cat and mouse with Boost devs by maintaining
MSYS patches that won't get accepted into official Boost tree.

I've been working recently on a library [1] derived from Boost::context,
but which can be easily added to any C++ project, as it consists only of
2 files (.h and .cpp), just like ClipperLib, which we successfully used
for processing polygons.

Libcontext contains all Boost::context switching functions converted to
inline assembly, with compiler and ABI detection. So far,
it has been tested on: i386/x86_64 Linux, Win32/Win64 (GCC) and OSX
(both 32 and 64-bit) - so all the platforms Kicad runs on are already
supported (I'll also enable ARM support - as soon as I have a working
test program a raspi). I think this should be sufficient for the
foreseeable future.

Best,
Tom

[1] https://github.com/twlostow/libcontext