Gonzalo,
Thanks for starting this discussion. I am willing to help with this effort
as I definitely need this capability. Part of the challenge will be
figuring out how to do this on Windows.
Eventually, I think we do want to capability to be built into Cython. But,
while we experiment with different approaches for nesting, windows support,
etc., it might make sense to keep it a separate, semi-stand alone
capability. This would also make it easier for me to contribute as I know 0
about the Cython code base.
In terms of syntax, I am not sure that the decorator approach would work.
The reason the that you probably don't want to enable this for entire
functions. Because it is such an invasive things, you want it on as little
as possible. Thus, I almost think the with syntax would work better:
with c_signals:
....
Thoughts?
Cheers,
Brian
On Sat, Mar 13, 2010 at 5:04 PM, Gonzalo Tornaria
<torna...@math.utexas.edu>wrote:
> On Sat, Mar 13, 2010 at 2:30 PM, Robert Bradshaw
> <rober...@math.washington.edu> wrote:
> > On Mar 13, 2010, at 5:29 AM, Nicolas M. Thiery wrote:
> >>
> >> def bla(...):
> >> with sig_on:
> >> if ...
> >> raise ...
> >> elif ...
> >> return
> >> ...
>
> This is exactly the required semantics. I didn't know cython supported
> with-guards. Are they lightweight enough? We really only want to add a
> call to _sig_on macro at start and a call to _sig_off macro at end,
> and no other bloat. the whole process should have very tiny overhead,
> except for the first call to _sig_on (when signal trapping is enabled:
> there must be a call to sigsetjmp(3) which is somehow costly). While
> nesting is not supported atm, it should, and nested calls to _sig_on
> should be almost overhead free as well.
>
> > Yes, for sure--I've been thinking about borrowing the with syntax as
> well.
> > Perhaps there could also be syntax/a decorator for marking an entire
> > function as getting and releasing the signal handler too (just as we have
> > with the GIL). As part of incorporating this into Cython, some syntactic
> > improvements should be considered. Any other ideas?
>
> What's the syntax for supporting the GIL? Something like that could
> work, I guess.
>
> Something along this lines:
>
> @with_sig_on
> def bla(...):
> if ...
> raise ...
> elif ...
> return
> ...
>
> Would be great (or whatever other syntax, like an attribute for the
> function, etc). The key point being that one can add or remove the
> "with_sig_on" without touching the function body. In the "with"
> syntax, the whole body needs to be reindented. Moreover, when there's
> a docstring, the "with" clause goes after the docstring, while the
> decorator syntax clearly displays at the top the fact that the
> function catches signals.
>
> The with clause is more flexible, though -- sometimes one wants to
> compute quickly (no signal catching) for small arguments (say you know
> the computation will be pretty fast) but catch the signals in other
> cases all in the same body.
>
> What are the options for supporting this (either the
> decorator/function attribute or the with-clause)?
>
> Gonzalo
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com<sage-devel%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
