[tbnl-devel] Problem with ppc/sbcl
I can't get TBNL to stay responsive reliably on SBCL/ppc (which is a no-threads platform). Among other things, it will block in read-line (get-apache-command) when the connection from apache has gone away. Hitting Control-C interrupts the read and pushes the process back to the place where it's accepting the new connection from apache. (Using mod_lisp2). Does anyone have experience with this platform? Is it expected to work? Thanks, --Chris -- Chris Austin-Lane - +1-301-270-6524 - chris@austin-lane.net The #6 Fundamental Truth: It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (RFC 1925)
Hi! On 2005-02-05 17:24:00, chris@austin-lane.net wrote:
I can't get TBNL to stay responsive reliably on SBCL/ppc (which is a no-threads platform). Among other things, it will block in read-line
I don't think this could work without a threading SBCL. TBNL uses KMRCL for starting a listener. Which itself just calls a function when there's no threading SBCL or another Common Lisp with multi-processing: #-(or allegro cmu lispworks sb-thread) (funcall func) Regards, Stefan
On 2005-02-06 02:52:34, Stefan Scholl wrote:
#-(or allegro cmu lispworks sb-thread) (funcall func)
This was with KMRCL 1.77. Current version is 1.78, which seems to support openmcl: processes.lisp: (defun make-process (name func) #+allegro (mp:process-run-function name func) #+cmu (mp:make-process func :name name) #+lispworks (mp:process-run-function name nil func) #+sb-thread (sb-thread:make-thread func) #+openmcl (ccl:process-run-function name func) #-(or allegro cmu lispworks sb-thread openmcl) (funcall func) )
"Stefan" == Stefan Scholl <stesch@no-spoon.de> writes:
Stefan> I don't think this could work without a threading Stefan> SBCL. TBNL uses KMRCL for starting a listener. Which Stefan> itself just calls a function when there's no threading Stefan> SBCL or another Common Lisp with multi-processing: Stefan> #-(or allegro cmu lispworks sb-thread) (funcall Stefan> func) Stefan, Thanks for the answer. Any opinion on whether it would be easier to hack tbnl to use the serve-event non-threads loop or switch a TBNL script to run under Araneida (which I understand but do not know does not require threads). I have an additional question, I am currently getting an encoding error because the input stream is :EXTERNAL-FORMAT :ASCII and the POST'ed matter is in UTF8 or Latin-1 or whatever. Anyone else see this? --Chris -- Chris Austin-Lane - +1-301-270-6524 - chris@austin-lane.net People do as much work in 7 40-hour weeks as in 7 50-hour weeks.
On Sun, 6 Feb 2005 09:31:47 -0500 (EST), <chris@austin-lane.net> wrote:
Thanks for the answer. Any opinion on whether it would be easier to hack tbnl to use the serve-event non-threads loop or switch a TBNL script to run under Araneida (which I understand but do not know does not require threads).
Hmm, no idea. You should search for an example of proper SERVE-EVENT usage (I seem to remember that Thomas Burdick posted something like that to the small-cl-sources list some time ago) and try to apply it to mod_lisp. I don't know enough of Araneida to answer the other half of the question. I'd be happy to accept clean patches to enable TBNL to use SERVE-EVENT.
I have an additional question, I am currently getting an encoding error because the input stream is :EXTERNAL-FORMAT :ASCII and the POST'ed matter is in UTF8 or Latin-1 or whatever. Anyone else see this?
You're talking about the data coming from the browser? That's strange. Do you have a simple example to reproduce that behaviour? Cheers, Edi.
"Edi" == Edi Weitz <edi@agharta.de> writes:
Edi> I'd be happy to accept clean patches to enable TBNL to use Edi> SERVE-EVENT. So clean patches are my current goal :) >> I have an additional question, I am currently getting an >> encoding error because the input stream is :EXTERNAL-FORMAT >> :ASCII and the POST'ed matter is in UTF8 or Latin-1 or >> whatever. Anyone else see this? Edi> You're talking about the data coming from the browser? Edi> That's strange. Do you have a simple example to reproduce Edi> that behaviour? I stopped this by setting the LC_ALL locale to en_US.UTF-8 before starting lisp, and adding an explicit chartset=UTF-8 to the webpages. My previous locale, Posix, caused lisp to use ASCII as the default :EXTERNAL-FORMAT (which caused it to reject chars > 127). thanks, --Chris -- Chris Austin-Lane - +1-301-270-6524 - chris@austin-lane.net "He is a self-made man &worships his creator." - John Bright
On Tue, 8 Feb 2005 06:03:11 -0500 (EST), <chris@austin-lane.net> wrote:
So clean patches are my current goal :)
Good... :)
I stopped this by setting the LC_ALL locale to en_US.UTF-8 before starting lisp, and adding an explicit chartset=UTF-8 to the webpages. My previous locale, Posix, caused lisp to use ASCII as the default :EXTERNAL-FORMAT (which caused it to reject chars > 127).
OK. This is the SBCL Unicode branch, right? Can it change the external format of a stream on the fly like CLISP and (I think) AllegroCL? Cheers, Edi.
"Edi" == Edi Weitz <edi@agharta.de> writes:
Edi> OK. This is the SBCL Unicode branch, right? Can it change Edi> the external format of a stream on the fly like CLISP and (I Edi> think) AllegroCL? According to #lisp, no (and that is recognized as a limitation). --Chris -- Chris Austin-Lane - +1-301-270-6524 - chris@austin-lane.net The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. - Fred Brooks, Jr.
participants (3)
-
chris＠austin-lane.net -
Edi Weitz -
Stefan Scholl