As mentioned in other emails, I am moving this thread to the ECL bug report system -- I helps me keep track of the problems, because going through unread emails has proven inefficient (reason why I forgot about this particular problem)

Followups here
https://sourceforge.net/p/ecls/bugs/216/

Juanjo


On Tue, Nov 27, 2012 at 4:40 PM, Jean-Pierre Flori <jpflori@gmail.com> wrote:
2012/11/27 Jean-Pierre Flori <jpflori@gmail.com>:
> 2012/11/27 Jean-Pierre Flori <jpflori@gmail.com>:
>> 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
screen:
^C^C...^C
as many times as the signal was not treated, and when it is finally I
get a final
^C
followed by as many oups as interrupts not caught
oupsoups...oups
(so this looks like:
^C...^C^Coups...oups
Condition of type: INTERACTIVE-INTERRUPT
Console interrupt

Available restarts:
...
)


--
Jean-Pierre Flori



--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com