# \`ccall\` macros for controlling SIGINT handling
**URL:** https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431
**Category:** Internals & Design
**Created:** [January 9, 2019, 9:20am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431 "2019-01-09T09:20:36Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 8, 2019, 10:30am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/1 "2019-01-08T10:30:57Z")
If you are wrapping ccall, another thing you can do is to wrap it with `disable_sigint` [C Interface · The Julia Language](https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable_sigint) so that you don’t have to worry when calling the C functions that may not be interrupt safe.
---
### Author:  [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)
#### Post date: [January 8, 2019, 11:24am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/2 "2019-01-08T11:24:20Z")
> [@Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement](https://discourse.julialang.org/t/wrote-a-macro-to-make-ccall-look-a-little-more-like-julia-need-an-opinion-on-the-return-type-placement/19373/5):
>
> If you are wrapping ccall, another thing you can do is to wrap it with `disable_sigint` [https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable\_sigint](https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable_sigint) so that you don’t have to worry when calling the C functions that may not be interrupt safe.
Good idea. (… two minutes later…) On the other hand, what about calls that block for a while and _are_ interrupt safe? Is that really something that should be automatic? maybe it should be a different macro? maybe an optional flag?
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 8, 2019, 9:21pm UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/3 "2019-01-08T21:21:56Z")
I think it’s better to have a safer default. If the C function is interrupt-safe, maybe just use `ccall`. A separate macro like `@interruptable_ccall` also makes sense.
See also: [https://github.com/JuliaLang/julia/issues/2622](https://github.com/JuliaLang/julia/issues/2622)
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 9, 2019, 12:26am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/4 "2019-01-09T00:26:13Z")
I see your point. It would be nice if there were builtin `interruptable_ccall`… Regarding the name, maybe just `@c` for `ccall` + `disable_sigint`? If you read it “at C do this” that’s kind of nice. Or maybe `@guardedccall` to emphasise that it’s not entirely “safe” (because it can’t be) but it’s guarded from something (= sigint).
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [January 9, 2019, 12:56am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/5 "2019-01-09T00:56:34Z")
Yes if you’re naming it `@ccall`, that should just be different syntax for `ccall`.
> [@Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement](https://discourse.julialang.org/t/wrote-a-macro-to-make-ccall-look-a-little-more-like-julia-need-an-opinion-on-the-return-type-placement/19373/5):
>
> wrap it with `disable_sigint` [https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable\_sigint](https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable_sigint) so that you don’t have to worry when calling the C functions that may not be interrupt safe.
It looks like `disable_sigint` far predates @yuyichao’s big cleanup of the interrupt delivery in [https://github.com/JuliaLang/julia/pull/16174](https://github.com/JuliaLang/julia/pull/16174). I’m not sure `disable_sigint` is even necessary anymore.
> [@Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement](https://discourse.julialang.org/t/wrote-a-macro-to-make-ccall-look-a-little-more-like-julia-need-an-opinion-on-the-return-type-placement/19373/13):
>
> determine if code is being run in a separate thread or task
A signal generated (for example) by Ctrl-C can be delivered even in a single threaded, single-`Task` environment — it’s a facility provided by the operating system (and a bit platform dependent, see [https://linux.die.net/man/2/signal](https://linux.die.net/man/2/signal) or [signal | Microsoft Learn](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal?view=vs-2017) for example).
Julia installs signal handlers for various internal things which users normally shouldn’t need to worry about, and from the look of the way `InterruptException` is now delivered you shouldn’t need to worry about these corrupting the state of code which you’ve `ccall`’d.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 9, 2019, 12:58am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/6 "2019-01-09T00:58:36Z")
> [@Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement](https://discourse.julialang.org/t/wrote-a-macro-to-make-ccall-look-a-little-more-like-julia-need-an-opinion-on-the-return-type-placement/19373/15):
>
> I’m not sure `disable_sigint` is even necessary anymore.
I think it is. See a recent discussion with @yuyichao in [https://github.com/JuliaPy/PyCall.jl/pull/574](https://github.com/JuliaPy/PyCall.jl/pull/574)
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [January 9, 2019, 1:06am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/7 "2019-01-09T01:06:56Z")
No, only if your c function can call back into Julia and doesn’t support longjmp (to be fair the second condition is likely to be the case if the first one is satisfied). Most c code don’t.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 9, 2019, 1:26am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/8 "2019-01-09T01:26:02Z")
I see. So I guess `@ccall` macro can wrap `ccall` with `disable_sigint` when it detects `@cfunction` is used in the expression it’s transforming. Not sure if it’s too much of a magic, though. Also, call to Julia can happen in other ways.
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [January 9, 2019, 1:35am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/9 "2019-01-09T01:35:19Z")
> [@Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement](https://discourse.julialang.org/t/wrote-a-macro-to-make-ccall-look-a-little-more-like-julia-need-an-opinion-on-the-return-type-placement/19373/17):
>
> only if your c function can call back into Julia and doesn’t support longjmp (to be fair the second condition is likely to be the case if the first one is satisfied)
Right, that makes sense. Perhaps it would be best to just leave sigint handling disabled inside julia code called by a `cfunction` so that people would have to opt for the unsafe behavior explicitly… as you say, the typical C code which is calling the typical `cfunction` won’t be longjmp safe. Is this feasible?
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [January 9, 2019, 3:03am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/10 "2019-01-09T03:03:43Z")
That’s not going to catch anything useful.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 9, 2019, 3:25am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/11 "2019-01-09T03:25:50Z")
Do you mean what I proposed was non-comprehensive and over-protecting? If so, I agree (I already mentioned that it was not comprehensive).
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [January 9, 2019, 4:22am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/12 "2019-01-09T04:22:16Z")
No, I mean it’s just a bad heuristic. It’s not just over protecting, it’s underprotecting at the same time. It doesn’t catch most (any?) cases in the pycall issue.
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [January 9, 2019, 4:43am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/13 "2019-01-09T04:43:13Z")
I understand. That’s why I said non-comprehensive.
---
### Author:  [@Per](https://discourse.julialang.org/u/Per)
#### Post date: [January 9, 2019, 6:55am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/14 "2019-01-09T06:55:10Z")
How about a syntax like
```julia
err = @C disable_sigint error_on_nonzero more_cowbell mkfifo(pathname::Cstring, mode::Cuint)::Cint
```
where symbols before the function call are flags that alter the behavior of the macro?
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [January 9, 2019, 7:08am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/15 "2019-01-09T07:08:30Z")
There’s nothing more we can do to improve the `SIGINT` handling in the `@ccall` macro; `ccall` itself already does a good job of this (see [#16174](https://github.com/JuliaLang/julia/pull/16174)).
If you want syntax for extra behavior, I’d suggest tacking them on as extra `key=value` pairs after the function signature (in analogy to `@test`). Though I’m not sure that makes sense if there’s no equivalent behavior in `ccall` itself.
---
### Author:  [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)
#### Post date: [January 9, 2019, 9:20am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/16 "2019-01-09T09:20:36Z")
I like the direction you’re going, but I think at that point it’s better just to chain macros `@disable_siginit @nonzero_err @ccall ...`, it’s not much longer, it reads about the same, and the implementation is simpler.
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [January 10, 2019, 2:46am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/17 "2019-01-10T02:46:16Z")
@yuyichao what’s the feasibility of deferring SIGINT within `@cfunction` generated wrappers by default? That would seem to be a reasonable heuristic, given that throwing `InterruptException` inside cfunction is likely to jump over (and corrupt) non-julia stack frames.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [January 10, 2019, 3:04am UTC](https://discourse.julialang.org/t/ccall-macros-for-controlling-sigint-handling/19431/18 "2019-01-10T03:04:49Z")
It’s easy to implement. As for the default, there are people who complains when the exceptions are thrown too aggressively and when the exceptions are thrown not aggressively enough so I have no opinion on that.