[Ecls-list] ECL debugger

Juan Jose Garcia Ripoll jlr at mpq.mpg.de
Wed May 19 01:49:03 UTC 2004


Hi Julian,

I just cross-posted this answer to the list, because it might be of 
interest for somebody else.

Julian Stecklina wrote:

>Juan Jose Garcia Ripoll <jlr at mpq.mpg.de> writes:
>
>>et si::*interrupt-enable* to NIL, ecl_interrupt_enable = 0 or install
>>your own signal handler using signal() :-)
>>    
>>
>The last obviously works. :) But ecl_interrupt_enable is only
>accessible from inside the ECL sources, it is not exported via ecl.h.
>
Because it is not for anybody to use it, and because the interface is 
not fixed :-) Just use #include "${prefix}/h/internal" and you're done. 
Or use "extern bool ecl_interrupt_enable" somewhere in your code, or 
just set the lisp variable.

I might just include "ecl_interrupt_enable" back in the ECL public 
headers, but the problem is that I am not very sure about the maturity 
of the signals interface and I would like somebody to think about it 
carefully before fixing anything.

For instance, in the presence of threads, one should be able to do the 
signal handling per-thread, and one should not simply deactivate _all_ 
signals because the lisp environment uses them to comunicate between 
threads (See MP:INTERRUPT-PROCESS, etc).

I would really appreaciate help on this respect, from people with more 
experience in this field. After all, the most complicated multithreaded 
application I have ever done was a port of Doom to OS/2, and that only 
had three threads.

Best regards,

Juanjo

-- 
Max-Planck-Institut fuer Quantenoptik	+49/(0)89/32905-345
Hans-Kopfermann-Str. 1, D-85748		www.mpq.mpg.de/Theorygroup/CIRAC/
Garching b. Muenchen, Germany		Juan.Ripoll at mpq.mpg.de






More information about the ecl-devel mailing list