Stefan Behnel, 18.03.2011 13:36:
We shouldn't forget that basically all Python operations can at least raise
a MemoryError or a KeyboardInterrupt etc. Most users won't think of these
cases. I think it would help users in writing safer code if the need to
handle exceptions in nogil blocks was alwa
On 18 March 2011 13:36, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 18.03.2011 12:07:
>>
>> On 03/18/2011 11:10 AM, Stefan Behnel wrote:
>>>
>>> Actually, I think I still find it more convenient to not provide *any*
>>> special exception paths through nogil code, i.e. to not let exceptions in
>>>
Dag Sverre Seljebotn, 18.03.2011 12:07:
On 03/18/2011 11:10 AM, Stefan Behnel wrote:
Actually, I think I still find it more convenient to not provide *any*
special exception paths through nogil code, i.e. to not let exceptions in
"with gil" blocks exit from outer "nogil" blocks. That would avoid
On 03/18/2011 11:10 AM, Stefan Behnel wrote:
mark florisson, 18.03.2011 10:52:
On 18 March 2011 07:07, Stefan Behnel wrote:
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- th
mark florisson, 18.03.2011 10:52:
On 18 March 2011 07:07, Stefan Behnel wrote:
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject
On 18 March 2011 07:07, Stefan Behnel wrote:
> Greg Ewing, 18.03.2011 01:18:
>>
>> mark florisson wrote:
>>>
>>> I think we could support it without having to acquire
>>> the GIL in the finally clause.
>>
>> That was the intention -- the code in the finally clause would
>> be subject to the same n
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject to the same nogil restrictions as the rest of
the nogil block.
My point is that as
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject to the same nogil restrictions as the rest of
the nogil block.
My point is that as long as you're allowing except
On 16 March 2011 20:16, mark florisson wrote:
Could someone review the patch (which is attached)? Maybe check if I
haven't missed any side cases and such?
>>>
>>> From a first look, the test file you added seems far too short. I would
>>> expect that this feature requires a lot more test
On 18 March 2011 00:32, Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> def f():
>> with nogil:
>> for ...:
>> A
>> if something_exceptional:
>> with gil:
>> raise Exception(...)
>> B
>> C
>
> If that's to be
Dag Sverre Seljebotn wrote:
def f():
with nogil:
for ...:
A
if something_exceptional:
with gil:
raise Exception(...)
B
C
If that's to be supported, the following really ought to be
supported as well:
On 17 March 2011 11:35, Dag Sverre Seljebotn wrote:
> On 03/17/2011 11:16 AM, mark florisson wrote:
>>
>> On 17 March 2011 10:08, Dag Sverre Seljebotn
>> wrote:
>>>
>>> How about this compromise: We balk on the code you wrote with:
>>>
>>> Error line 345: Exceptions propagating from "with gil" bl
On 03/17/2011 11:16 AM, mark florisson wrote:
On 17 March 2011 10:08, Dag Sverre Seljebotn wrote:
How about this compromise: We balk on the code you wrote with:
Error line 345: Exceptions propagating from "with gil" block cannot be
propagated out of function, please insert try/except and hand
On 17 March 2011 09:27, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 17.03.2011 08:38:
>>
>> On 03/17/2011 12:24 AM, Greg Ewing wrote:
>>>
>>> Stefan Behnel wrote:
>>>
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them
On 17 March 2011 10:08, Dag Sverre Seljebotn wrote:
> On 03/17/2011 09:27 AM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 17.03.2011 08:38:
>>>
>>> On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
> I'm not sure if this is a good idea. "nogil" blocks don't hav
On 03/17/2011 09:27 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 17.03.2011 08:38:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a
way to
handle exceptions, so simply jumping out of them because an inner
'with
Dag Sverre Seljebotn, 17.03.2011 08:38:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them because an inner 'with
gil' block raised an exception can have unexpec
On 03/17/2011 08:38 AM, Dag Sverre Seljebotn wrote:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way
to handle exceptions, so simply jumping out of them because an inner
'with gil' block raised an exception can
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way
to handle exceptions, so simply jumping out of them because an inner
'with gil' block raised an exception can have unexpected side effects.
Seems to me that the
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them because an inner 'with
gil' block raised an exception can have unexpected side effects.
Seems to me that the __Pyx_WriteUnraisable should be done at
th
On 03/16/2011 01:55 PM, mark florisson wrote:
but it doesn't catch this:
cdef void func() nogil:
with nogil:
pass
with nogil:
func()
I would say that in that case, func() should acquire the
gil on entry so that it can be released in the 'with nogil'
block.
Either that or
mark florisson wrote:
I just think it is important for users
to realize that in general, they cannot unblock threads recursively.
I don't think that nested 'with nogil' blocks in any way
suggest that they can. Saying 'with nogil' means "I want
this code executed with the gil released". If it's
>>> Could someone review the patch (which is attached)? Maybe check if I
>>> haven't missed any side cases and such?
>>
>> From a first look, the test file you added seems far too short. I would
>> expect that this feature requires a lot more testing in combination with
>> declared and undeclared l
On 16 March 2011 16:14, Stefan Behnel wrote:
> mark florisson, 16.03.2011 11:28:
>>
>> I implemented the 'with gil:' statement
>> [...]
>> The 'with gil:' statement can now be used in the same way as 'with
>> nogil:'. Exceptions raised from GIL blocks will be propagated if
>> possible (i.e., if th
On 03/16/2011 02:17 PM, Pauli Virtanen wrote:
Wed, 16 Mar 2011 14:10:29 +0100, Dag Sverre Seljebotn wrote:
Ah, right. I guess I agree with disallowing nested "with nogil"
statements for the time being then.
Could you make the inner nested "with nogil" statements no-ops instead,
if the GIL is al
mark florisson, 16.03.2011 15:29:
On 16 March 2011 15:07, Stefan Behnel wrote:
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and s
mark florisson, 16.03.2011 11:28:
I implemented the 'with gil:' statement
[...]
The 'with gil:' statement can now be used in the same way as 'with
nogil:'. Exceptions raised from GIL blocks will be propagated if
possible (i.e., if the return type is 'object'). Otherwise it will
jump to the end of
Wed, 16 Mar 2011 14:10:29 +0100, Dag Sverre Seljebotn wrote:
> Ah, right. I guess I agree with disallowing nested "with nogil"
> statements for the time being then.
Could you make the inner nested "with nogil" statements no-ops instead,
if the GIL is already released? Does the Cython compiler kee
On 16 March 2011 15:07, Stefan Behnel wrote:
> mark florisson, 16.03.2011 13:28:
>>
>> On 16 March 2011 13:01, mark florisson wrote:
>
> Another feedback is that I wonder whether we should put the "gil" and
> "nogil" psuedo-context managers both in cython namespace, and sort of
> d
Dag Sverre Seljebotn, 16.03.2011 13:37:
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
I think we should make nested nogil-s noops, i.e.
with nogil:
with nogil: # => if True:
This is because one may want to change "with nogil" to "with gi
Dag Sverre Seljebotn, 16.03.2011 11:58:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with n
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and sort of
deprecate the "global" nogil, rather than introduce yet another name that
ca
On 03/16/2011 01:55 PM, mark florisson wrote:
On 16 March 2011 13:37, Dag Sverre Seljebotn wrote:
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn
wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and hav
On 16 March 2011 13:55, mark florisson wrote:
> On 16 March 2011 13:37, Dag Sverre Seljebotn
> wrote:
>> On 03/16/2011 12:54 PM, mark florisson wrote:
>>>
>>> On 16 March 2011 11:58, Dag Sverre Seljebotn
>>> wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented
On 16 March 2011 13:37, Dag Sverre Seljebotn wrote:
> On 03/16/2011 12:54 PM, mark florisson wrote:
>>
>> On 16 March 2011 11:58, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 03/16/2011 11:28 AM, mark florisson wrote:
>>>
>>> I implemented the 'with gil:' statement, and have added error checking
>>>
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch
On 16 March 2011 13:01, mark florisson wrote:
>>> Another feedback is that I wonder whether we should put the "gil" and
>>> "nogil" psuedo-context managers both in cython namespace, and sort of
>>> deprecate the "global" nogil, rather than introduce yet another name that
>>> can't be used safely f
>> Another feedback is that I wonder whether we should put the "gil" and
>> "nogil" psuedo-context managers both in cython namespace, and sort of
>> deprecate the "global" nogil, rather than introduce yet another name that
>> can't be used safely for all kinds of variables.
>
> Hmm, good catch. Act
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
> On 03/16/2011 11:28 AM, mark florisson wrote:
>
> I implemented the 'with gil:' statement, and have added error checking
> for nested 'with gil' or 'with nogil' statements. For instance, with
> the patch applied Cython wil issue an error when y
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with nogil:
with nogil:
...
(or
40 matches
Mail list logo
