From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Grover Newsgroups: gmane.lisp.guile.user Subject: Re: mod_lisp for guile Date: Mon, 19 Sep 2005 23:24:34 -0400 Message-ID: <432F80F2.4080605@mail.msen.com> References: <4329AE76.4000606@mail.msen.com> <871x3ohmv0.fsf@ossau.uklinux.net> <432ECF41.4080500@mail.msen.com> <87br2ozqul.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1127187172 15146 80.91.229.2 (20 Sep 2005 03:32:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Sep 2005 03:32:52 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 20 05:32:46 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EHYqp-000170-Dd for guile-user@m.gmane.org; Tue, 20 Sep 2005 05:31:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHYqo-0000yS-Pd for guile-user@m.gmane.org; Mon, 19 Sep 2005 23:31:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EHYpi-0000S5-VH for guile-user@gnu.org; Mon, 19 Sep 2005 23:30:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EHYpf-0000Q8-7I for guile-user@gnu.org; Mon, 19 Sep 2005 23:30:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHYpe-0000OH-VX for guile-user@gnu.org; Mon, 19 Sep 2005 23:30:11 -0400 Original-Received: from [148.59.80.48] (helo=ww8.msen.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EHYkI-0008C6-3b for guile-user@gnu.org; Mon, 19 Sep 2005 23:24:38 -0400 X-Sent-To: Original-Received: from [192.168.1.220] (pool-151-196-115-140.balt.east.verizon.net [151.196.115.140]) (authenticated bits=0) by ww8.msen.com (8.13.4/8.13.4) with ESMTP id j8K3OYG2018773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2005 23:24:35 -0400 (EDT) (envelope-from awgrover@mail.msen.com) User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en Original-To: guile-user@gnu.org In-Reply-To: <87br2ozqul.fsf@ossau.uklinux.net> X-Milter: Spamilter (Reciever: ww8.msen.com; Sender-ip: 151.196.115.140; Sender-helo: [192.168.1.220]; ) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4753 Archived-At: Neil Jerram wrote: (much elision) > It seems to me, though, that there is nothing especially lispy about > the module (mod_lisp) which runs inside Apache. Presumably the Apache > side of the protocol could be implemented in any language, or could be > provided "native" by Apache itself? It's in C. Nothing lispy here. It could be native, but, since it is not essential to an HTTP server, it is left as a module. > Is the form of the protocol itself lispy? (I.e. parenthesised and > readable using read.) The protocol is not lispy. It sends each header as: header-name header-value with an "end" as the last header-value. Several "daemon-side" implementations have been written in other languages. I think it is only called mod_lisp because it was originally written for use with Common Lisp. > How would using threads reduce resource usage? Otherwise this all > makes sense. A thread doesn't require an entire process (like a fork does), in particular, memory is shared. I think you could limit a thread's resource requirements to just an execution "thread" (PC, registers, stack), otherwise sharing everything within the one process. Being light-weight/cheap is one of the major motivations for threads. Though I read something recently that claimed some thread (mis-)implementations are more costly than a fork, and often more costly than you'd hope. Apparently, the Linux 2.6 thread implementation is in user-space, which means it isn't very thrifty (and causes some other interesting issues). > So you mean that if someone has already written an HTTP request > handler procedure for use with www-guile, it ought to be possible to > reuse exactly that same procedure with your mod-lisp also? Sounds > good to me. Also, I don't want to rewrite all the logic from that module (e.g. query-parsing, etc. etc.). My goal is to allow no change between CGI and mod_lisp (for certain www library modules). Perl's CGI module transparently works under CGI or mod_perl (an embedded Perl interpreter in the Apache process). >>The interface in the first release is a function that loops, calling >>your function for each request. So, it kind of takes over. It occurred >>to me that there might be more polite ways of working. At the very >>least, there should be mechanisms that impose the least policy. > > > Yes, indeed. This problem isn't specific to web requests, of course. > It applies to pretty much any socket-driven or GUI (event-driven) > library. (For example, the (ossau gds-client) module in my > guile-debugging package.) > > It would be nice to have a SRFI which standardised the way of > specifying handler procedures for such events, and of determining when > each such event source had work to process, along with standard > procedures for doing blocking and non-blocking selects on all the > events, and so on. I look forward to your work on the issue. :) I kind of like the lazy-list solution, but I've been infected by a pure-and-lazy programming language (Clean). I think some people call them generators. I'm liking the lazy-list idea more and more. It seems to work well with the tcp-socket listener pattern. The old way: ; off in somebodies library module ; It "takes over" (define (daemon-loop handler) set-up listener Repeat forever: block on accept spawn thread with accepted socket and handler ) ; In your code (define (my-handler ...) ; called in a new-thread do-something) ; we will now loop forever on accept/spawn (daemon-loop my-handler) With a lazy-list, it would be something like ; In your code (define mod_lisp-request (make-lazy-mod-lisp with-appropriate-tcp-code)) ; Whatever "daemon-loop" you want: (for-each spawn-my-thread mod_lisp-request) >>So, assuming I provided lazy-mod-lisp: >> (define lazy-results (lazy-mod-lisp socket-port)) >> >> (pair? lazy-results) ; -> #t. maybe not, I'd have to check >> >> ; actually does the work to figure out first mod-lisp request. could >>block! >> (define first (car lazy-results)) ; might need "force" > > Yes, and blocking is the problem. The application usually needs to > know when it can call this without blocking. An interesting problem given the apparent PThreads implementations (any blocking-call blocks all threads). In my prototype code, I "soft" block (just block the one thread), using 'select. In this case, it is probably OK (and expected) that the 'car would "soft" block (until the next request comes in), since this is the daemon-loop. You could push this loop into its own thread, and leave your "main" thread unblocked. Under PThreads, I am lead to believe that each "read", if it blocks, blocks the entire process (all threads). But, under reasonable circumstances, the blocking should be very short. However, if the Apache side of mod_lisp is slow in writing, it would cause problems. > I see. So combining my thoughts and yours, I think this would have > three levels to it. > > - Generic API for specifying sources of input and how to handle them. Well, I'm only addressing mod_lisp at the moment. Though I intend to let the user (programmer) supply the socket-listener (or whatever they want that results in a read/write port that appears to talk mod_lisp). I'd be happy to work with you to extract the (to be written) lazy-list stuff for general use. You might want to look at Perl's Net modules. They are layered something like you suggest: a generic TCP layer, a generic header-value/body protocol, specific protocols like HTTP or SMTP. > - The particular case of this API for an HTTP request handler. > > - Your ideas for presenting the HTTP content in various useful ways. I have plans for several more layers for web-applications. E.g. a web-application skeleton (get request, decode request, change state, decide on html, construct html), and layers of policy to fill it with (e.g. a particular html-template system). Though I've heard about continuation-passing web-frameworks, I'm not currently working on them. Also, since I use Guile, there is the problem that you can't use a continuation in a different thread. > I hope > it's of some interest though. I have been interested. And, I thank you for taking the time. -- Alan Grover _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user