On 10/2/05, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 10/3/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> > On 10/1/05, Antoine <[EMAIL PROTECTED]> wrote:
> > >
> > > > like this with their "deferred objects", no? I figure they would
> > > > need to do something like this too. I will h
On 10/3/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> On 10/1/05, Antoine <[EMAIL PROTECTED]> wrote:
> >
> > > like this with their "deferred objects", no? I figure they would
> > > need to do something like this too. I will have to check.)
> >
> > A Deferred object is just the abstraction of a c
On 10/1/05, Antoine <[EMAIL PROTECTED]> wrote:
>
> > like this with their "deferred objects", no? I figure they would
> > need to do something like this too. I will have to check.)
>
> A Deferred object is just the abstraction of a callback - or, rather, two
> callbacks: one for success and one f
On 10/2/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> One of the problems that you have with using generators like
> this, is that automatic "yield" on resource access does not occur
> automatically, like it does in threading. With threads, the
> kernel is invoked when access to a low-level resour
On Saturday 01 October 2005 22:50, Martin Blais wrote:
...
> because some people on the list appear to discuss generators as
> a concurrency scheme, and as far as I know they really are not
> addressing that at all.
Our project started in the context of dealing with the task of a
naturally concurr
Hi Martin,
[snip]
The "confusion" stems from the fact that two issues are mixed up in this
discussion thread:
- improving concurrency schemes to make it easier to write well-behaving
applications with independent parallel flows
- improving concurrency schemes to improve performance when there ar
Hi.
I hear a confusion that is annoying me a bit in some of the
discussions on concurrency, and I thought I'd flush my thoughts
here to help me clarify some of that stuff, because some people
on the list appear to discuss generators as a concurrency scheme,
and as far as I know (and please correct
On Fri, 2005-09-30 at 18:33 +0200, Antoine Pitrou wrote:
> Hi Jp,
>
> Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit :
> > "Advocating" might be putting it too strongly :) "Experimenting with"
> > describes the current state of things most accurately.
>
> Ok :)
>
> > The prob
> I was just saying that it can be useful to mix cooperative threading and
> preemptive threading in the same app, i.e. have different domains of
> cooperative threading which are preemptively scheduled by the OS. That
> has nothing to do with the GIL, I think (but I don't know much in Python
> int
Hi Jp,
Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit :
> "Advocating" might be putting it too strongly :) "Experimenting with"
> describes the current state of things most accurately.
Ok :)
> The problem it aims to solve is integration with cooperative threading
> systems w
On Fri, 30 Sep 2005 17:26:27 +0200, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>Hi,
>
>> I've never heard
>> someone complain that the GIL is in the way for these types of apps.
>
>I've never said so either.
>I was just saying that it can be useful to mix cooperative threading and
>preemptive thre
Hi,
> I've never heard
> someone complain that the GIL is in the way for these types of apps.
I've never said so either.
I was just saying that it can be useful to mix cooperative threading and
preemptive threading in the same app, i.e. have different domains of
cooperative threading which are p
Le vendredi 30 septembre 2005 à 07:32 -0700, Simon Wittber a écrit :
> I use this approach extensively, using tasks which are defined using
> generators. The scheduler I developed for this can be viewed here:
>
> http://metaplay.dyndns.org:82/svn/nanothreads/nanothreads.py
FWIW, I've coded my ow
On 9/30/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le vendredi 30 septembre 2005 à 08:32 -0500, [EMAIL PROTECTED] a écrit :
> > >> (C) That scheduler is non-preemptive. A single greedy generator can
> > >> starve all the others.
> >
> > Antoine> Instead of looking at this as
On 9/30/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > (C) That scheduler is non-preemptive. A single
> > greedy generator can starve all the others.
>
> Instead of looking at this as a problem, you could look at it as a
> feature. Since generators can't be switched at arbitrary places, the
Le vendredi 30 septembre 2005 à 08:32 -0500, [EMAIL PROTECTED] a écrit :
> >> (C) That scheduler is non-preemptive. A single greedy generator can
> >> starve all the others.
>
> Antoine> Instead of looking at this as a problem, you could look at it
> Antoine> as a feature.
>
>> (C) That scheduler is non-preemptive. A single greedy generator can
>> starve all the others.
Antoine> Instead of looking at this as a problem, you could look at it
Antoine> as a feature.
Apple looked at it as a feature for years. Not anymore.
Skip
_
> (C) That scheduler is non-preemptive. A single
> greedy generator can starve all the others.
Instead of looking at this as a problem, you could look at it as a
feature. Since generators can't be switched at arbitrary places, the
programmer has to define his/her synchronization points explicit
18 matches
Mail list logo
