[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] 1095 (prerelease) + some eggs
From: |
Joerg F. Wittenberger |
Subject: |
Re: [Chicken-users] 1095 (prerelease) + some eggs |
Date: |
25 Feb 2003 09:49:57 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
> > (let loop ()
> > (handle-exceptions
> > ex (exception-handler ex)
> > (receive
> > (in-port out-port) (tcp-accept request-queue)
> > (receive
> > (local remote) (tcp-addresses in-port out-port)
>
> ^
> `tcp-addresses' takes only a single argument. Normally, your
> exception-handler should logerr something. Are you compiling in
> safe mode?
Yes I do. Apparently the execution doesn't reach the point.
How to I control the size of the stacktrace? Except for the exception
handler I see only profiling calls and then the deadlock when
thread-join! is reached.
> > (with-exception-handler
> > ex (begin (close-output-port out-port) (loop)))))
>
> Argh! Very wrong and very dangerous: the first arg to
> `with-exception-handler' must be the handler itself and the second
Horror. Thanks. What a shame. Looks as if this wanted to become a
handle-exceptions, doesn't it? I just try to avoid handle-exceptions
if the code allows me to do, because it saves a call/cc! I'm not
claiming that my way is actually worth the risk of such mistakes.
> One question: SRFI-18 says that an uncaught exception is stored
> in the end-exception field of a thread and that the thread should
> terminate. If the parent now join!s,
> that uncaught exception will be raised. The problem is that errors
> in child-threads are not reported to the user, which makes debugging
> challenging, but not exactly fun.
As I understand, the exception is then raised in the context of the
joining thread, which in turn is responsible to handle (report) the
exception, isn't it?
> Should the default exception handler still invoke `error'? No,
affirm: the default exception handler must not invoke error, because
it no longer is. Another, joining, thread might have a handler for
the exception.
> because that would throw back to toplevel (without storing something
> in the end- exception field).
right.
> So what should it do?
>
> 1) Terminate silently, and store the end-exception
yes plus...
> 2) If not the primordial thread: Print a message to stderr and store it,
> otherwise invoke `error'
> 3) something else
when the scheduler finds the last thread dying, print the result. The
result is the end-exception field, if this is set, otherwise the value
of the thunk which was run in the thread.
/Jörg
--
The worst of harm may often result from the best of intentions.
Re: [Chicken-users] 1095 (prerelease) + some eggs, William Annis, 2003/02/24