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)
2012/11/27 Jean-Pierre Flori <email@example.com>:
> 2012/11/27 Jean-Pierre Flori <firstname.lastname@example.org>:Nonetheless there is something fishy here.
>> 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.
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