2012/11/27 Jean-Pierre Flori <jpflori@...>:
> 2012/11/27 Jean-Pierre Flori <jpflori@...>:
>> 2012/11/27 Jean-Pierre Flori <jpflori@...>:
>>> OK I think I got it.
>>> The culprit is commit 880259cb5533913a6c09d6c99d8d26a22e1b9195.
>>> I hirst thought that the following change was to be blamed:
>>> --- a/src/c/main.d
>>> +++ b/src/c/main.d
>>> @@ -77,7 +77,7 @@
>>> 1, /* ECL_OPT_TRAP_SIGCHLD */
>>> 1, /* ECL_OPT_TRAP_INTERRUPT_SIGNAL */
>>> 1, /* ECL_OPT_SIGNAL_HANDLING_THREAD */
>>> - 128, /* ECL_OPT_SIGNAL_QUEUE_SIZE */
>>> + 16, /* ECL_OPT_SIGNAL_QUEUE_SIZE */
>>> 0, /* ECL_OPT_BOOTED */
>>> 8192, /* ECL_OPT_BIND_STACK_SIZE */
>>> 128, /* ECL_OPT_BIND_STACK_SAFETY_AREA */
>>> but changing this back in git HEAD from some time yesterday does not
>>> fix the issue.
> Nonetheless there is something fishy here.
> If I expand the if (record != ECL_NIL) test in queue_signal in
> src/c/unixint.d to have an else clause containing printf("oups");,
> then when interrupts are not completely caught I get printed on
> as many times as the signal was not treated, and when it is finally I
> get a final
> followed by as many oups as interrupts not caught
> (so this looks like:
> Condition of type: INTERACTIVE-INTERRUPT
> Console interrupt
I think the oredring of ^C and oups is just some artifact of caching.
> Available restarts:
I might have found a simpler way to get this: just launch ecl and then
press CTRL+C, you'll get an ^Coups, repress them and the interurpt
will get caught.
And if try the same thing with a thread enabled ECL, the interrupt get
caught, but when I quit ECL just after, I get a segfault which seems
to happen at the end of asynchronous_signal_servicing_thread().
PS: just saw your email, I'll redirect this to the bug tracker.