[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