Here is an email I received from Tobias in response to my suggestion to wrap the body of invocations of WITH-CONNECTED-SOCKET with a WITH-MAPPED-CONDITIONS. We discussed his comment afterwards and came to the conclusion that it will be problematic to get nested occurences of WITH-CONNECTED-SOCKET to work if the all of the handlers for any of the involved conditions declines. For conditions signalled with ERROR (which is what usocket needs to do anyway) this will be no problem, as ERROR itself will invoke the debugger if all handlers decline. With SIGNAL, the behavior Tobias describes could be observed, which would clearly be unwanted.
-Hans
---------- Forwarded message ---------- From: Tobias C. Rittweiler tcr@freebits.de Date: 26.03.2008 13:55 Subject: Re: WITH-MAPPED-CONDITIONS and other WITH-* macros To: Hans Hübner hans.huebner@gmail.com
"Hans Hübner" hans-zv1TXXZFLoBAfugRpC6u6w@public.gmane.org writes:
Hi,
how would you feel about adding a WITH-MAPPED-CONDITIONS to the expansion of WITH-CONNECTED-SOCKET? The reason for that is that it is possible that stream read/write operations on a socket stream generate socket errors that need conversion.
Thoughts?
I'm not familiar with the usocket source base, but I found out yesterday the hard way that remapping conditions that work properly when being nested is entirely not trivial.
CL-USER> (handler-bind ((warning #'(lambda (w) (format t "<1> ~S~%" w) (signal w)))) (handler-bind ((warning #'(lambda (w) (format t "<2> ~S~%" w) (signal (make-condition 'warning))))) (warn "FOO")))
<2> #<SIMPLE-WARNING {B7060A1}> ; created by the (warn "FOO") <1> #<WARNING {B706CE1}> ; created by the (make-condition 'warning) <1> #<SIMPLE-WARNING {B7060A1}> ; same as in <2> <-- WE DON'T WANT THIS TO HAPPEN WARNING: FOO NIL
The problem is that handler <2> signals the conditions _anew_, but if this newly signalled condition isn't handled anywhere upwards, the condition that was originally signalled continues its search for a handler further upwards (causing handler <1> to be run twice.)
The problem is that there's no RESIGNAL operator (or a DECLINE) operator in Common Lisp, making this really troublesome.
My point is that: If WITH-CONNECTED-SOCKET is supposed to work when being nested (or if multiple WITH-MAPPED-CONDITIONS can appear in the extent of a WITH-CONNECTED-SOCKET), you have to be careful not to screw up.
HTH,
-T.
-- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner
On 3/26/08, Hans Huebner hans.huebner@gmail.com wrote:
Here is an email I received from Tobias in response to my suggestion to wrap the body of invocations of WITH-CONNECTED-SOCKET with a WITH-MAPPED-CONDITIONS. We discussed his comment afterwards and came to the conclusion that it will be problematic to get nested occurences of WITH-CONNECTED-SOCKET to work if the all of the handlers for any of the involved conditions declines. For conditions signalled with ERROR (which is what usocket needs to do anyway) this will be no problem, as ERROR itself will invoke the debugger if all handlers decline. With SIGNAL, the behavior Tobias describes could be observed, which would clearly be unwanted.
Well, Tobias indicates absense of RESIGNAL or DECLINE, but when a handler returns from a SIGNALled condition, in handler-bind, that's considered a DECLINE.
If you want to make an explicit RESIGNAL, you can simply take the 'w' parameter to the handler function and (SIGNAL w) again. Note that that's a new invocation of SIGNAL, which in itself can return. If you decide to handle a returning SIGNAL by returning yourself from the handler function, that's also considered a DECLINE. In the case of SIGNAL, that means the SIGNAL statement will return NIL and continue execution.
Does that not allow you to do what you want to do? I mean... you can get a single printed line in the output below by just returning from your handler (removing the SIGNAL statement).
Does that explain the condition system a bit?
HTH,
Erik.
---------- Forwarded message ---------- From: Tobias C. Rittweiler tcr@freebits.de Date: 26.03.2008 13:55 Subject: Re: WITH-MAPPED-CONDITIONS and other WITH-* macros To: Hans Hübner hans.huebner@gmail.com
"Hans Hübner" hans-zv1TXXZFLoBAfugRpC6u6w@public.gmane.org writes:
Hi,
how would you feel about adding a WITH-MAPPED-CONDITIONS to the expansion of WITH-CONNECTED-SOCKET? The reason for that is that it is possible that stream read/write operations on a socket stream generate socket errors that need conversion.
Thoughts?
I'm not familiar with the usocket source base, but I found out yesterday the hard way that remapping conditions that work properly when being nested is entirely not trivial.
CL-USER> (handler-bind ((warning #'(lambda (w) (format t "<1> ~S~%" w) (signal w)))) (handler-bind ((warning #'(lambda (w) (format t "<2> ~S~%" w) (signal (make-condition 'warning))))) (warn "FOO")))
<2> #<SIMPLE-WARNING {B7060A1}> ; created by the (warn "FOO") <1> #<WARNING {B706CE1}> ; created by the (make-condition 'warning) <1> #<SIMPLE-WARNING {B7060A1}> ; same as in <2> <-- WE DON'T WANT THIS TO HAPPEN WARNING: FOO NIL
The problem is that handler <2> signals the conditions _anew_, but if this newly signalled condition isn't handled anywhere upwards, the condition that was originally signalled continues its search for a handler further upwards (causing handler <1> to be run twice.)
The problem is that there's no RESIGNAL operator (or a DECLINE) operator in Common Lisp, making this really troublesome.
My point is that: If WITH-CONNECTED-SOCKET is supposed to work when being nested (or if multiple WITH-MAPPED-CONDITIONS can appear in the extent of a WITH-CONNECTED-SOCKET), you have to be careful not to screw up.
HTH,
-T.
-- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner _______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
2008/3/26, Erik Huelsmann ehuels@gmail.com:
On 3/26/08, Hans Huebner hans.huebner@gmail.com wrote:
Here is an email I received from Tobias in response to my suggestion to wrap the body of invocations of WITH-CONNECTED-SOCKET with a WITH-MAPPED-CONDITIONS. We discussed his comment afterwards and came to the conclusion that it will be problematic to get nested occurences of WITH-CONNECTED-SOCKET to work if the all of the handlers for any of the involved conditions declines. For conditions signalled with ERROR (which is what usocket needs to do anyway) this will be no problem, as ERROR itself will invoke the debugger if all handlers decline. With SIGNAL, the behavior Tobias describes could be observed, which would clearly be unwanted.
Well, Tobias indicates absense of RESIGNAL or DECLINE, but when a handler returns from a SIGNALled condition, in handler-bind, that's considered a DECLINE.
If you want to make an explicit RESIGNAL, you can simply take the 'w' parameter to the handler function and (SIGNAL w) again. Note that that's a new invocation of SIGNAL, which in itself can return. If you decide to handle a returning SIGNAL by returning yourself from the handler function, that's also considered a DECLINE. In the case of SIGNAL, that means the SIGNAL statement will return NIL and continue execution.
Does that not allow you to do what you want to do? I mean... you can get a single printed line in the output below by just returning from your handler (removing the SIGNAL statement).
I'm fine with using ERROR in the signal handler to resignal the converted condition. Tobias could not post to the list himself and after discussing with him off-list, we agreed that I should forward his concerns to the list. I have also added a warning comment to the source code reminding what declining means. Patch to follow.
-Hans
-
Erik Huelsmann -
Hans Huebner