at-atomic macro as alternative to disable_sigint()

[kmsquire]

While working on VideoIO, I was unaware of disable_sigint, and created a macro which disables interrupts around sections of code:

macro atomic(code)
    quote
        Base.sigatomic_begin()
        ret = ($code)
        Base.sigatomic_end()
        ret
    end
end

Even after discovering disable_sigint, I like this a little better, especially for single ccalls (or in the case of VideoIO, wrapped ccalls):

@atomic av_freep(c)  # function which wraps ccall((:av_freep,libavutil),Void,(Ptr{Void},),ptr)

Is there interest in having this in Base? If so, I'll submit a PR.

Cc: @stevengj

[yuyichao]

FWIW, you probably want a try-catch block to make it more generic.

[kmsquire]

@yuyichao, makes sense, thanks!

[tkelman]

There are a few too many meanings of the term "atomic" for this to claim the @atomic name in base I think, but maybe @sigatomic ? How widely used would this be? Should it eventually be automatic for ccalls, ref #2622?

[kmsquire]

There are a few too many meanings of the term "atomic" for this to claim the @atomic name in base I think, but maybe @sigatomic?

Okay.

How widely used would this be?

Probably about as widely as sigatomic_begin and sigatomic_end (or disable_sigint) are used now, which is to say, not very widely. grep for these gives GTK, PyCall, and VideoIO, and one use in Base, with no sign of disable_sigint. (There might be more, but I don't have that many packages installed).

Should it eventually be automatic for ccalls, ref #2622?

Possibly, but from the conversation there, this wasn't a slam dunk, as it has a significant impact on ccalls to simple functions (e.g., sqrt).

Anyway, I'll put a PR together with the changes suggested here, ping the relevant parties, and see if there's more interest.

[stevengj]

From my perspective, it was a slam dunk. As was pointed out in that thread, functions where a couple of instrutions are simple enough to matter, e.g. sqrt, should be (and are now, in the case of sqrt) inlined.

[kmsquire]

Okay, I missed that. In that case, automatically disabling interrupts for ccalls sounds good.

[ScottPJones]

@kmsquire doesn't it really depend on just how long the ccall is going to take? Disabling interrupts can be pretty nasty. In my previous job, we set up a different handler, instead of disabling, and also let that be selectable (some callouts were just fast things implemented in C, and didn't need to set up a different handler, nor wanted any time spent to do so).

[JeffBezanson]

I still don't like it much. It's just not really "the right thing"; the fact that you're calling code in another language is only a very loose heuristic for whether interrupts should be disabled. It would only make slightly less sense to pick 200 places in the code at random to disable interrupts. And as you increase that number, ^C gets more and more reliable.

[carnaval]

I want the final say on at least 10 of those 200.

[stevengj]

It's a much better heuristic than the one we have now (interrupts are opt-out). Basically, ctrl-C is a random deathtrap at the moment.

[stevengj]

Is there a real example of a ccall that we would want to be interruptable?

[yuyichao]

All julia runtime?

[stevengj]

@yuyichao, in the Julia runtime functions you can easily opt-in because they have access to julia.h.

[JeffBezanson]

Anyway, @sigatomic is a nicer interface than the current 4 functions (sigatomic_begin, sigatomic_end, disable_sigint, reenable_sigint).

[stevengj]

@JeffBezanson, I use the lower-level functions to re-enable interrupts in Julia callbacks (e.g. from Python or NLopt), so I would prefer not to eliminate them entirely.