At 5:27 PM +0000 3/15/04, Arthur Bergman wrote:On 15 Mar 2004, at 17:25, Jeff Clites wrote:
We shouldn't, I would think, be snagging any signals unless user code expresses an interest in the signal. The default disposition of every signal is either to be ignored, or to abruptly terminate the process, and we preserve that behavior if we just do nothing, unless someone does the parrot analog of registering a signal handler. That works equally well in embedded and non-embedded environments.
Jeff
No it doesn't, because an embedding environment might not want to let parrot deal with signals, ever, and it might feel to restrict when it sends them off. Signals are an environment issue and thus should be controlled from the host app.
Yeah. We're ultimately going to have to add signals to memory allocation and IO as things that the embedding environment controls.
Yeah, that would be nice for a managed environment. But in the general (non-managed) embedding case, I should be able to avoid having a signal handler installed automatically, yet still allow bytecode to register a signal handler for me. That is, I wouldn't want to completely disable creation of signal handlers in parrot, in order to avoid having one installed automatically.
But anyway, I thought the call to Parrot_sigaction(SIGINT, ...) inside of Parrot_init_signals() was just for testing purposes anyway.
JEff
