If you are wrapping ccall, another thing you can do is to wrap it with disable_sigint C Interface · The Julia Language so that you don’t have to worry when calling the C functions that may not be interrupt safe.

[image] Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement 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 so that you don’t have to worry…

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

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 …

Yes if you’re naming it @ccall, that should just be different syntax for ccall. [image] Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement wrap it with disable_sigint https://docs.julialang.org/en/v1.2-dev/base/c/#Base.disable_sigint so that …

Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement 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

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.

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.

[image] Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement 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 make…

That’s not going to catch anything useful.

Do you mean what I proposed was non-comprehensive and over-protecting? If so, I agree (I already mentioned that it was not comprehensive).

`ccall` macros for controlling SIGINT handling

Internals & Design

tkf January 9, 2019, 12:58am 6

I think it is. See a recent discussion with @yuyichao in https://github.com/JuliaPy/PyCall.jl/pull/574

Topic		Replies	Views
Interrupts and `@spawn` with `ccall` General Usage	1	405	January 2, 2020
Wrote a macro to make ccall look a little more like Julia. Need an opinion on the return type placement General Usage	33	3145	January 24, 2019
How to interrupt a long-running ccall C/C++ library? General Usage question , ccall	1	302	August 24, 2023
Create a custom @ccall New to Julia ccall , macros	4	204	July 22, 2024
Segmentation fault on ccall General Usage ccall , bug , debug	6	1683	November 11, 2017

`ccall` macros for controlling SIGINT handling

Related topics