Skip to content

Conversation

@kliem
Copy link
Collaborator

@kliem kliem commented Sep 2, 2021

We provide the addresses of PARI_SIGINT_block and PARI_SIGINT_pending on runtime in python functions, such that cysignals can use it with try ... except ImportError.

@dimpase dimpase requested a review from videlec October 14, 2021 17:52
@kliem
Copy link
Collaborator Author

kliem commented May 21, 2022

@videlec

Any opinions about this approach? This would make it lots easier to build cysignals and cypari along with https://github.com/kliem/cysignals/tree/discover_cypari_on_runtime/src/cysignals.

The behaviour should be equivalent to the current approach.

@videlec
Copy link
Collaborator

videlec commented May 23, 2022

Sounds reasonable. One problem I see with this approach is that loading cysignals will load cypari2 (or at least cypari2.paridecl). Ideally, cysignals should have an abstract mechanism to plug in third-party libraries signal handling. And then it would be the job of cypari2 to plug itself in cysignals at load time.

@kliem
Copy link
Collaborator Author

kliem commented May 23, 2022

You mean that it should be cypari's responsibility to call a specialized sig_check and sig_on that sets the correct pointers for PARI_SIGINT_block and PARI_SIGINT_pending. Only problem I see with this is nested sig_on, but that could be made illegal for this case (so to the additional SIGINT_block SIGINT_pending the sig_on_count must always be 0).

@videlec
Copy link
Collaborator

videlec commented May 23, 2022

Not sure I agree. I wanted to suggest that cysignals could be configurable via hooks. There should be a single implementation of sig_on/sig_off/sig_check inside cysignals. But it should be possible to plug extra steps to cysigs_interrupt_handler via hooks (one has to design a generic enough protocol though).

@kliem
Copy link
Collaborator Author

kliem commented May 23, 2022

When should the hooks be called?

@videlec
Copy link
Collaborator

videlec commented May 23, 2022

  • cypari2 would insert its hooks in cysignals at load time of cypari2
  • cysignals would call these hooks in its cysigs_interrupt_handler. More precisely, cysignals should have a stack of hooks and go through them any time an interruption occurs.

Maybe it is not feasible. I am trying to find a flexible enough solution so that cysignals becomes cypari2 agnostic.

@mkoeppe
Copy link

mkoeppe commented May 28, 2022

  • cypari2 would insert its hooks in cysignals at load time of cypari2
  • cysignals would call these hooks in its cysigs_interrupt_handler. More precisely, cysignals should have a stack of hooks and go through them any time an interruption occurs.

+1 on this approach

This was referenced May 30, 2022
@videlec videlec force-pushed the master branch 4 times, most recently from 28f2382 to 3660f17 Compare November 11, 2022 10:08
@mkoeppe
Copy link

mkoeppe commented Mar 16, 2024

@kliem Closing because it is superseded by #130 if I'm not mistaken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants