C blocks are very similar to Go function literals or Ecmas6 arrow
functions. I was thinking on either using {} or just having it through
identation with ():
So instead of:
def function():
def inner():
# something
loop.call(inner)
You'd do:
def function():
loop.call( lambda (arg1, arg2, **kwargs) :
# something
)
Also, we don't have real CSP - since we have GIL all implementations are
really just toying with the ideas.
The pain point I'm talking about here is such - we introduce a lot of ways
to structure code, but they don't give the benefits present in other
languages. I'm starting to think we have too much cruft in .py
2016-06-21 16:17 GMT+02:00 Omer Katz <omer.d...@gmail.com>:
> I’m not familiar with C blocks and GCD.
> How would Python code look with that approach?
>
> On 20 Jun 2016, at 6:02 PM, Michał Domański <mdom...@gmail.com> wrote:
>
> So I actually thought about similar approach. I was curious what do you
> think about approach to concurrency similar to what Apple did with C blocks
> and GCD. That is: enable threading but instead of the STM approach have
> fully explicit mutations within atomic blocks
>
> 2016-06-20 16:53 GMT+02:00 Armin Rigo <ar...@tunes.org>:
>
>> Hi Omer,
>>
>> On 20 June 2016 at 08:51, Omer Katz <omer.d...@gmail.com> wrote:
>> > As for implementation, if we can trace the code running in the thread
>> and
>> > ensure it's not mutating global state and that CPyExt is never used
>> during
>> > the thread's course we can simply release the GIL when such a thread is
>> run.
>>
>> That's a very hand-wavy and vague description. To start with, how do
>> you define exactly "not mutating global state"? We are not allowed to
>> write to any of the objects that existed before we started the thread?
>> It may be possible to have such an implementation, yes. Actually,
>> that's probably easy: tweak the STM code to crash instead of doing
>> something more complicated when we write to an old object.
>>
>> I'm not sure how useful that would be---or how useful PyParallel is on
>> CPython. Maybe if you can point us to real usages of PyParallel it
>> would be a start.
>>
>>
>> A bientôt,
>>
>> Armin.
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev@python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> ---------------------------
> Michał Domański
>
>
>
--
---------------------------
Michał Domański
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
