From peter.barabas at gmail.com  Thu May  5 17:41:56 2005
From: peter.barabas at gmail.com (Peter BARABAS)
Date: Thu, 5 May 2005 19:41:56 +0200
Subject: [tbnl-devel] TBNL stream
Message-ID: <4f2a8db5050505104172a7be4f@mail.gmail.com>

Hello,

TBNL expects a string to be returned from the dispatch functions,
which it will send to the HTTP client. Is there a stream that I can
output my HTML to, to avoid consing?

Thank you in advance.

-- 
'(Yours parenthetically),
peter barabas.

((call/cc call/cc) (call/cc call/cc))


From edi at agharta.de  Thu May  5 20:41:10 2005
From: edi at agharta.de (Edi Weitz)
Date: Thu, 05 May 2005 22:41:10 +0200
Subject: [tbnl-devel] TBNL stream
In-Reply-To: <4f2a8db5050505104172a7be4f@mail.gmail.com> (Peter BARABAS's
	message of "Thu, 5 May 2005 19:41:56 +0200")
References: <4f2a8db5050505104172a7be4f@mail.gmail.com>
Message-ID: <ud5s5wgm1.fsf@agharta.de>

On Thu, 5 May 2005 19:41:56 +0200, Peter BARABAS <peter.barabas at gmail.com> wrote:

> TBNL expects a string to be returned from the dispatch functions,
> which it will send to the HTTP client. Is there a stream that I can
> output my HTML to, to avoid consing?

Not directly, no.  This is a deliberate design decision of TBNL which
has the advantage that at any time during the generation of the output
TBNL's error handling (or yours) can intervene and send something
meaningful to the client instead of, say, half a page of HTML followed
by junk.

I've used TBNL for lots of different web apps and I've also
benchmarked it more than once.  I've never experienced a bottleneck
due to this.  Do you have actual performance problems or is this just
pre-mature optimization?  Have you profiled your code?

BTW, another important point is that mod_lisp will close the socket to
Lisp on each request unless you send a valid "Content-Length" header.
In most cases this is impossible unless you capture your output before
sending it to mod_lisp.  Having to re-open a socket on each request
might as well be much more expensive than consing up a string.

Cheers,
Edi.

PS: I might not be able to answer for a couple of days because I'll be
    on vacation.


From peter.barabas at gmail.com  Fri May  6 20:33:51 2005
From: peter.barabas at gmail.com (Peter BARABAS)
Date: Fri, 6 May 2005 22:33:51 +0200
Subject: [tbnl-devel] TBNL stream
In-Reply-To: <ud5s5wgm1.fsf@agharta.de>
References: <4f2a8db5050505104172a7be4f@mail.gmail.com>
	<ud5s5wgm1.fsf@agharta.de>
Message-ID: <4f2a8db50505061333729eb68a@mail.gmail.com>

On 5/5/05, Edi Weitz <edi at agharta.de> wrote:
> On Thu, 5 May 2005 19:41:56 +0200, Peter BARABAS <peter.barabas at gmail.com> wrote:
> 
> > TBNL expects a string to be returned from the dispatch functions,
> > which it will send to the HTTP client. Is there a stream that I can
> > output my HTML to, to avoid consing?
> 
> Not directly, no.  This is a deliberate design decision of TBNL which
> has the advantage that at any time during the generation of the output
> TBNL's error handling (or yours) can intervene and send something
> meaningful to the client instead of, say, half a page of HTML followed
> by junk.

I see. It's a reasonable design philosophy.

> I've used TBNL for lots of different web apps and I've also
> benchmarked it more than once.  I've never experienced a bottleneck
> due to this.  Do you have actual performance problems or is this just
> pre-mature optimization?  Have you profiled your code?

The truth is that I was just curious. I haven't had a performance
issue with TBNL.

> BTW, another important point is that mod_lisp will close the socket to
> Lisp on each request unless you send a valid "Content-Length" header.
> In most cases this is impossible unless you capture your output before
> sending it to mod_lisp.  Having to re-open a socket on each request
> might as well be much more expensive than consing up a string.

Indeed. Thanks for the details.

I hope my question wasn't too stupid.

-- 
'(Yours parenthetically),
peter barabas.

((call/cc call/cc) (call/cc call/cc))


From peter.barabas at gmail.com  Sun May 22 18:46:24 2005
From: peter.barabas at gmail.com (Peter BARABAS)
Date: Sun, 22 May 2005 20:46:24 +0200
Subject: [tbnl-devel] Problem while starting TBNL
Message-ID: <4f2a8db505052211464cbd71ff@mail.gmail.com>

Greetings,


I've upgraded TBNL and SBCL and have faced a problem. This is how I load
TBNL:

(asdf:operate 'asdf:load-op 'tbnl)
(asdf:oos 'asdf:load-op :tbnl-test)
(tbnl:start-tbnl)

Error while trying to start listener on port 3000
  Can't create a new thread


I don't even get dropped in the debugger. I'm using SBCL 0.9.0.19 under
Linux 2.4.27.

*FEATURES*:

(:ASDF :SB-FUTEX
       :SB-THREAD
       :ANSI-CL
       :COMMON-LISP
       :SBCL
       :UNIX
       :SB-DOC
       :SB-TEST
       :SB-PACKAGE-LOCKS
       :SB-UNICODE
       :IEEE-FLOATING-POINT
       :X86
       :ELF
       :LINUX
       :GENCGC
       :STACK-GROWS-DOWNWARD-NOT-UPWARD
       :C-STACK-IS-CONTROL-STACK
       :STACK-ALLOCATABLE-CLOSURES
       :LINKAGE-TABLE
       :OS-PROVIDES-DLOPEN
       :OS-PROVIDES-DLADDR)

May that be the problem that SBCL doesn't support threading under 2.4.x,
however *FEATURES* does contain :SB-THREAD?

Thanks for you help.

-- 
'(Yours parenthetically),
peter barabas.

((call/cc call/cc) (call/cc call/cc))


From stesch at no-spoon.de  Sun May 22 19:41:19 2005
From: stesch at no-spoon.de (Stefan Scholl)
Date: Sun, 22 May 2005 21:41:19 +0200
Subject: [tbnl-devel] Problem while starting TBNL
In-Reply-To: <4f2a8db505052211464cbd71ff@mail.gmail.com>
References: <4f2a8db505052211464cbd71ff@mail.gmail.com>
Message-ID: <20050522194119.GK4395@parsec.no-spoon.de>

Hi!

On 2005-05-22 20:46:24, Peter BARABAS wrote:
> May that be the problem that SBCL doesn't support threading under 2.4.x,
> however *FEATURES* does contain :SB-THREAD?


>From NEWS:


changes in sbcl-0.8.21 (0.9alpha.1?) relative to sbcl-0.8.20:
  * incompatible change: thread support for non-NPTL systems has
    been removed - locking is buggy and unreliable.  A threaded
    SBCL build will now warn at startup and refuse to create
    new threads, unless futex support is detected in the kernel


So it may have the feature compiled in, but doesn't do anything
unless you have NPTL (Kernel 2.6, or 2.4 with a backport).


Regards,
Stefan