Re: [Kicad-developers] KiCad Coroutines

2016-01-21 Thread Tomasz Wlostowski
On 21.01.2016 13:06, "Torsten Hüter" wrote: > Hi, > > Lorenzo: > > Sorry, perhaps I've expressed it not correctly in my latest mail, I've just > written down my subjective impressions, while working on the code, that are > mostly rhetoric questions. > >>> Stackless coroutines: >>>

Re: [Kicad-developers] KiCad Coroutines

2016-01-21 Thread Torsten Hüter
Hi,   Lorenzo:   Sorry, perhaps I've expressed it not correctly in my latest mail, I've just written down my subjective impressions, while working on the code, that are mostly rhetoric questions.   >> Stackless coroutines: >> - >> >> * Relative easy to handle, because based

Re: [Kicad-developers] KiCad Coroutines

2016-01-21 Thread Kristian Nielsen
Lorenzo Marcantonio writes: > OTOH I never did that on Win32/64 so maybe it's totally undependable to work > :D > Isn't there some MSDN article on doing that? On windows, fibers can be used, and seem to work well. On most other platforms, ucontext can be used (only

Re: [Kicad-developers] KiCad Coroutines

2016-01-21 Thread Lorenzo Marcantonio
On Wed, Jan 20, 2016 at 11:58:56PM +0100, "Torsten Hüter" wrote: > * It's very tricky to get stackful implementations to run stable. Any small > fault results in a crash or deadlock. What's strange in that? When doing pointers even small faults give you a crash (if you are lucky :D). > * The

Re: [Kicad-developers] KiCad Coroutines

2016-01-21 Thread Torsten Hüter
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

Re: [Kicad-developers] KiCad Coroutines

2016-01-20 Thread Torsten Hüter
Hi Tom, I've uploaded now a few different implementations on my personal branch: https://code.launchpad.net/~torstenhtr/+junk/coroutines I've tried, as I've written in my first mail, Windows Fibers and Pthreads. I've implemented a "stress test" to compare the implementations and also

Re: [Kicad-developers] KiCad Coroutines

2016-01-15 Thread Torsten Hüter
Hi Tom,   I'm working on some alternatives, that I'm getting a better impression. I'll upload the example code this weekend, then we can discuss. One alternative are for instance stackless coroutines. I've also checked how you're using them in your code and have some ideas to modify that.  

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Maciej Sumiński
On 01/07/2016 11:39 AM, "Torsten Hüter" wrote: > 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]

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Lorenzo Marcantonio
On Thu, Jan 07, 2016 at 12:29:17PM +0100, Kristian Nielsen wrote: > In my experience, it is important not to underestimate the value of > co-routines for larger event-driven systems / state machines. Small systems The Knuth book has one *huge* chapter for coroutines. In assembly. The target has

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Mário Luzeiro
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? Mario ___ Mailing list: https://launchpad.net/~kicad-developers Post to :

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Lorenzo Marcantonio
On Thu, Jan 07, 2016 at 11:39:24AM +0100, "Torsten Hüter" wrote: > Ideally rendering and gui handling should happen only in the main > thread; but that would be to restrictive for our purposes. Are we sure doing GUI calls in event handling is a good idea? Since win 3.1 the recommended way was to

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Lorenzo Marcantonio
On Thu, Jan 07, 2016 at 12:06:08PM +0100, Maciej Sumiński wrote: > Tools in the Tool Framework never directly interact with OpenGL context. > Even if they request some redrawing/refreshing, it happens in OnPaint > (or similar) event handler. OK that's what I was worried about :D 100% agree with

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Torsten Hüter
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

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Lorenzo Marcantonio
On Thu, Jan 07, 2016 at 12:58:11PM +0100, jp charras wrote: > However I am not sure it is "thread based". > Threads are used to manage the stack using C++ language only. > I am not sure they are used to manage coroutines themselves. My fault, didn't read all the article. Actually it only use the

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Lorenzo Marcantonio
On Thu, Jan 07, 2016 at 01:24:18PM +0100, Edwin van den Oetelaar wrote: > I have done some embedded work in which these cooperative concepts happened. > by using co-routines this way you gain perceived concurrency but no real > increased power. It's not done for concurrency, only for flow

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Kristian Nielsen
Lorenzo Marcantonio writes: > On Thu, Jan 07, 2016 at 12:08:22PM +, Mário Luzeiro wrote: > 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

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Edwin van den Oetelaar
Hello all, In that case, take a look at http://dunkels.com/adam/pt/examples.html for inspiration. (proto-threads) Greetings, Edwin van den Oetelaar On Thu, Jan 7, 2016 at 1:39 PM, Lorenzo Marcantonio < l.marcanto...@cz-dynamic.it> wrote: > On Thu, Jan 07, 2016 at 01:24:18PM +0100, Edwin van

Re: [Kicad-developers] KiCad Coroutines

2016-01-07 Thread Wayne Stambaugh
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 +, 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

Re: [Kicad-developers] KiCad Coroutines

2016-01-06 Thread Tomasz Wlostowski
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

Re: [Kicad-developers] KiCad Coroutines

2016-01-06 Thread Wayne Stambaugh
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

Re: [Kicad-developers] KiCad Coroutines

2016-01-05 Thread Torsten Hüter
Hi Jean-Pierre, this is a good argument, if Boost does not have to be compiled anymore. I'll see what I can do and give feedback, at least an alternative was then tried. @Mark: Pthreads are standardised, because they're part of the POSIX family of standards

Re: [Kicad-developers] KiCad Coroutines

2016-01-05 Thread Mark Roszko
>Pthreads are standardised I meant it in a cross platform availability sense. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help

Re: [Kicad-developers] KiCad Coroutines

2016-01-04 Thread Torsten Hüter
a standard library foundation.   Thanks, Torsten     Gesendet: Montag, 04. Januar 2016 um 06:07 Uhr Von: "Mark Roszko" <mark.ros...@gmail.com> An: "Torsten Hüter" <torsten...@gmx.de> Cc: "KiCad Mailinglist" <kicad-developers@lists.launchpad.net>

Re: [Kicad-developers] KiCad Coroutines

2016-01-04 Thread jp charras
; <mark.ros...@gmail.com> > *An:* "Torsten Hüter" <torsten...@gmx.de> > *Cc:* "KiCad Mailinglist" <kicad-developers@lists.launchpad.net> > *Betreff:* Re: [Kicad-developers] KiCad Coroutines > >Summary: Fibers (Windows) and Pthreads (all POSIX-co

Re: [Kicad-developers] KiCad Coroutines

2016-01-04 Thread Wayne Stambaugh
test an alternative implementation, to drop another >> Boost >> dependency and build upon a standard library foundation. I'm fine with this as long as @Tom is OK with it and it's not too disruptive. Cheers, Wayne >> Thanks, >> Torsten >> *Gesendet:* Montag, 04. Januar 2016 u

Re: [Kicad-developers] KiCad Coroutines

2016-01-04 Thread Mark Roszko
>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 <.< C+11 threads are standard library not pthreads ^^ Ideal implementation is in a way that can be swapped for the C++11

Re: [Kicad-developers] KiCad Coroutines

2016-01-03 Thread Torsten Hüter
Hi Wayne,   > What version(s) of Windows support fibers? I didn't see any indication > on the links above.   See this link: https://support.microsoft.com/en-us/kb/128531 Fibers were added to the WIN32-API with the Service Pack 5 for Windows NT 3.51. Quote from the above link: "[..] Service

Re: [Kicad-developers] KiCad Coroutines

2016-01-03 Thread Mark Roszko
>Summary: Fibers (Windows) and Pthreads (all POSIX-compliant operating systems) >seem to be the most promising alternatives for context switching Since msys2 uses mingw, it used to have a pthreads implementation when I used it years ago. Not sure if the latest has a package for it. >I did

Re: [Kicad-developers] KiCad Coroutines

2016-01-03 Thread Wayne Stambaugh
On 1/3/2016 1:18 PM, "Torsten Hüter" wrote: > Hi Wayne, > > I've recently tried to compile KiCad on Windows (64Bit) and I've noticed that > PcbNew is crashing at context switching - but I had no problems early 2015 > with that. I've seen that you have already filed a bug report [1]. I did some