Re: Parrot hijacks SIGINT

On Mar 15, 2004, at 9:30 AM, Dan Sugalski wrote:

> 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