kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/7/2016 7:53 AM, Tomasz Wlostowski wrote:
> On 07.01.2016 13:34, Lorenzo Marcantonio wrote:
>> On Thu, Jan 07, 2016 at 12:08:22PM +0000, Mário Luzeiro wrote:
>>> Hi all,
>>>
>>> Sorry I don't know nothing about co-routines. Just curious, Why
>>> and where kicad is using it? And why and where kicad need
>>> multi-threading?
>>
>> It's not multithreading, it's suspending a thread of work in the
>> new tool code.
>>
>> Some thing like this: - Select a tool (suspend for a selection) -
>> Other things happens, then user select a thing - (restart the tool
>> coroutine) Check thing selected and so on
>>
>> The goal is *not* to use multiple cores or doing things in
>> background; the idea is to stop inside a function and then resume
>> from there when something desiderable happens.
>>
> 
> I agree, the whole idea was to simplify event handling in the tool, so
> instead of writing a complex state machine, you could just suspend the
> execution of your tool code to wait for a matching event:
> 
> @Edwin: Coroutines are not a replacement for threads. They *aren't*
> there for improving performance, just to simplify event handling in
> complex state machines. For example:
> 
> case 1) - without coroutines - we need to code a (possibly large) FSM
> by hand. This doesn't scale well in terms of code complexity,
> especially if there are nested state machines .
> 
> void handle_event(event)
> {
> switch(state)
> {
> case state1:
> if (event == event1) {
> do something();
> state = state2;
> }
> case state2:
> if (event == event2) {
> do_something();
> state = state3;
> }
> case state3:
> /// and so on
> }
> }
> 
> case 2) - with coroutines - we can execute our FSM in sequential code
> and receive events using a wait() function, which yields the current
> coroutine (i.e. transfers the control to the master event loop in case
> of pcbnew) and wakes up the execution of the tool that called wait()
> when a matching event arrives:
> 
> void my_tool()
> {
> 	wait(event1);
> 	do_something();
> 	wait(event2);
> 	do_something_else();
> }
> 
> All of the stack switching "magic" is hidden. You can find an example in
> include/tool/examples/coroutine_example.cpp
> 
> 
> Concerning boost::context, I see two options:
> - get rid of the coroutines (i.e. rewrite all event loops/calls in the
> GAL tools). Painful but doable, I would prefer to spend my time doing
> something more productive (e.g. porting the remaining tools to GAL).
> - turn boost::context into a single .cpp file library that one can
> just add to the project and forget about it (think of ClipperLib as an
> example).

After following this thread, I'm leaning towards Tom's opinion and
thinking that sticking with boost::context may be the least painful path
forward.  As of right now, the only place boost context is giving us
trouble is 64 bit windows builds.  I have already documented the work
around for msys2/mingw64 in the compiling KiCad developer doc.  Before
we dump boost context into the KiCad source, we should try to fix the 64
bit windows version current boost context switching library.  There are
now assembly files for building the boost context library on windows
using the gnu assembler so the boost devs appear to have changed their
minds about only using masm on windows.  Perhaps we can send a patch to
the msys2 folks who are very responsive to bug fix patches and push the
changes upstream to boost.  I'm not opposed to adding boost context to
our source repo but this always seems to me to be against one of the
major advantages of using open source software which is everyone
benefiting from bug fixes and improvements.  If we make local changes to
boost context to fix our problem and do not provide a patch to resolve
the problem to the boost project, then we are not helping out the
community at large.  Given that I am writing this email using
Thunderbird, using emacs as my editor, gcc as my compiler, bash as my
shell, etc., I think we should make our best effort at pushing fixes
upstream even though is a bit more work.

Wayne

> 
> As a side comment, I'm not surprised that boost devs insist on using
> MASM under Windows - the syntax of the GNU assembler on x86/x86_64
> platforms is just disgusting.
> 
> Tom
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>