Conversation
clisp (or less likely usocket) doesn't allow socket operations, other than close, after an error; it exits with code 141. CL+SSL might produce an error e.g. during implicit force-outputs. DRAKMA's http-request then calls its close method in an unwind-protect cleanup form, which calls force-output again. This second call causes clisp to exit. The following semantics for close seem sensible: If you've received an error operating with a plain-text or CL+SSL socket, then call close with :abort T. Use :abort NIL only when you've encountered no errors. When close is used that way, the problem gets solved. CL+SSL's close doesn't call force-output when :abort is T.
|
I would like to see this fixed, but the logic was already difficult to understand, and now with the additional |
|
Or maybe clisp should be fixed? |
|
I don't fully understand the original cleanup clause, but here is what I did. The changed version is equivalent to the original except that in one case it closes with abort T instead of abort NIL. This was the original cleanup clause. which, swapping the last two outer AND terms, is equivalent to which is which is which is I then finally changed the behaviour to what I wanted, which was to change the NIL to T in the (not done) situation. (That situation represents that an error occurred in the unwind-protect's body.) |
clisp (or less likely usocket) doesn't allow socket operations, other than close, after an error; it exits with code 141. CL+SSL might produce an error e.g. during implicit force-outputs. DRAKMA's http-request then calls its close method in an unwind-protect cleanup form, which calls force-output again. This second call causes clisp to exit. The following semantics for close seem sensible: If you've received an error operating with a plain-text or CL+SSL socket, then call close with :abort T. Use :abort NIL only when you've encountered no errors. When close is used that way, the problem gets solved. CL+SSL's close doesn't call force-output when :abort is T.