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:
>>>
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
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
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
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
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
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.
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]
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
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 :
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
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
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
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
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
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
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
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
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
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
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
>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
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>
; <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
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
>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
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
>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
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
29 matches
Mail list logo