On Sat, 22 Jan 2011 00:15:35 +0100
Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
> Well, then I think I might know the problem. If this is a multithreaded ECL,
> when SIGINT is received, it is handled by a separate thread. However, this
> thread is spawned by a thread which is created before your code is executed.
> In other words, the handler thread never gets to see your restarts. At most
> the *debugger-hook* might be used to "push" restarts, but not that they do
> not make much sense, since they are executed on a standalone thread, where
> the notion of "continue" does not make much sense.
It is indeed a multithreaded ECL build. However that particular
application doesn't need multiple threads (but indeed two threads can
be shown running). I've been wondering if it would be easy to create
non-threaded final executables from a threaded ECL build, but I think
it'd be a lot of trouble, as there are C macros expanding differently,
etc. I also could have two ECL builds to do that however. But I think
I'll keep using the threaded version which usually works fine, and
allows to discover potential bugs.
As for the SIGINT issue, I think that it would be solved if I left the
main thread for SWANK and used another thread for the main loop, which
is something I have done previously for a test HTTP server, but I admit
I still have to run that under -current ECL, it's been a while.
> In an "ordinary" ECL the situation is a bit different, as the debugger is
> better "installed" and what it does is coordinate with the already running
> toplevel. I will look into your examples, which are clear and simple enough,
> to see what is going on there -- the third example is particularly ugly.
I also received an interesting suggestion from another list reader:
Polos Ruetz <polos.ru...@gmail.com> wrote:
In my projects, in order to have the top level always executing, I
start them like so:
(with-input-from-string (s "(my-ini-code)") ; custom ini code
(let ((*standard-input* s))
(si:top-level)))
(Just a suggestion, maybe there's a better way.)
Thanks for the suggestion, here is an adapted test-case:
(defvar *input* *standard-input*)
(defun custom ()
(let ((*standard-input* *input*))
(format t "~%Let's read~%")
(read-line)
(format t "~%Done~%"))
(ext:quit))
(restart-case
(with-input-from-string (s "(custom)") ; custom ini code
(let ((*standard-input* s))
(si:top-level)))
(my-restart ()
(format t "~%ABORTING!~%")
(ext:quit)))
(ext:quit)
For this stdin I/O test case, obviously I had to remember
*standard-input* and rebind it before read-line, otherwise an immediate
EOF error would occur (under which case as with other type of
conditions MY-RESTART was available). If I type CTRL-C to send a
SIGINT in this case, I get the exact same behavior than before,
however. And I now understand why after your explanation about how
SIGINT is dealt with in threaded mode.
Thanks,
--
Matt
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
