Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly.
Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here.
You might point out I can find it out all by myself by reading the source code, but unfortunately I couldn't. Maybe I'm missing something. Can anyone here, please, point me to the answer? Thanks.
Hom
On Mon, Feb 04, 2008 at 11:44:48PM +0330, Mostafa Razavi wrote:
Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly.
Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here.
Special variables are global variables done right, and aren't to be dreaded in Common Lisp.
In threaded Lisps, binding a special will typically make it thread-local. For example, in SBCL:
http://www.sbcl.org/manual/Special-Variables.html
Zach
Oh! So basically definitions are global, bindings thread-local. That makes sense. Thanks, Zach.
Hom
Zach Beane wrote:
On Mon, Feb 04, 2008 at 11:44:48PM +0330, Mostafa Razavi wrote:
Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly.
Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here.
Special variables are global variables done right, and aren't to be dreaded in Common Lisp.
In threaded Lisps, binding a special will typically make it thread-local. For example, in SBCL:
http://www.sbcl.org/manual/Special-Variables.html
Zach _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi
Mostafa Razavi hom.sepanta@gmail.com writes:
Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly.
Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here.
Also see http://www.gigamonkeys.com/book/variables.html, footnote 11 and the applicable text.
Nico
You might point out I can find it out all by myself by reading the source code, but unfortunately I couldn't. Maybe I'm missing something. Can anyone here, please, point me to the answer? Thanks.
Hom _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Thanks, Nico. It's good to read books carefully. I had already read PCL but I hadn't noticed that.
Hom
Nico de Jager wrote: Also see http://www.gigamonkeys.com/book/variables.html, footnote 11 and the applicable text.
Nico
Hello group,
when I'm trying to asdf-load hunchentoot 0.15 in clisp 2.41[2], I'm receiving the following error message[1].
The problem is that Luís Oliveira's name in two files, port-clisp.lisp and unix-clisp.lisp, is encoded with latin-1, while clisp expects utf-8, as explained here[3].
BTW, his name spelling is inconsistent in these two files, and according to [4], Luís Oliveira is the right one.
My patch to fix that behaviour is below[5] (it fixes the issue for clisp and hunchentoot still compiles on SBCL) - I basically saved both files in utf-8 and changes Luís' name spelling in port-clisp.lisp - although I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.
Regards, Victor.
[1] Error message:
;; Compiling file /home/victor/src/clbuild/source/hunchentoot/port-clisp.lisp ... *** - invalid byte sequence #xED #x76 #x65 in CHARSET:UTF-8 conversion The following restarts are available: RETRY :R1 Retry performing #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x000333DCB850>. ACCEPT :R2 Continue, treating #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x000333DCB850> as having been successful. ABORT :R3 ABORT Break 1 [2]>
[2] clisp --version
victor@esculap:~/src/clbuild/source/hunchentoot$ clisp --version GNU CLISP 2.41 (2006-10-13) (built on victor-desktop [127.0.1.1]) Software: GNU C 4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2) /usr/bin/gcc-4.1 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -x none libcharset.a libavcall.a libcallback.a /usr/lib/libreadline.so -lncurses -ldl -L/usr/lib -lsigsegv SAFETY=0 TYPECODES WIDE GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.4 libreadline 5.2 Features: (ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER CLX-ANSI-COMMON-LISP CLX READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) C Modules: (clisp i18n syscalls regexp readline linux clx) Installation directory: /usr/lib/clisp/ User language: ENGLISH Machine: X86_64 (X86_64) esculap.gateway.2wire.net [192.168.1.73]
[3] http://objectmix.com/lisp/339187-unicode-file-clisp.html
[4] http://www.cl-user.net/asp/l1-A5/sdataQ0So-oWAO7WqDQ3XMHpX8yBX8yBXnMq=/sdata...
[5]
diff -rN -u old-hunchentoot/port-clisp.lisp new-hunchentoot/port-clisp.lisp --- old-hunchentoot/port-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 +++ new-hunchentoot/port-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 @@ -1,7 +1,7 @@ ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*- ;;; $Header: /usr/local/cvsrep/hunchentoot/port-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
-;;; Copyright (c) 2006, Luis Olíveira loliveira@common-lisp.net. +;;; Copyright (c) 2006, LuÃs Oliveira loliveira@common-lisp.net. ;;; Copyright (c) 2007, Anton Vodonosov avodonosov@yandex.ru. ;;; Copyright (c) 2007, Dr. Edmund Weitz. ;;; All rights reserved. diff -rN -u old-hunchentoot/unix-clisp.lisp new-hunchentoot/unix-clisp.lisp --- old-hunchentoot/unix-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 +++ new-hunchentoot/unix-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 @@ -1,7 +1,7 @@ ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*- ;;; $Header: /usr/local/cvsrep/hunchentoot/unix-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
-;;; Copyright (c) 2006, Luís Oliveira loliveira@common-lisp.net. +;;; Copyright (c) 2006, LuÃs Oliveira loliveira@common-lisp.net. ;;; Copyright (c) 2007, Anton Vodonosov avodonosov@yandex.ru. ;;; Copyright (c) 2007, Dr. Edmund Weitz. ;;; All rights reserved.
Transliteration to latin characters may make sense here, as it was originally done by Luís: http://common-lisp.net/~loliveira/patches/serve-event.diff.
BTW, clisp default encoding depends on your locale, it is not necessary utf-8: http://clisp.cons.org/clisp.html#opt-enc.
Best regards, -Anton
Victor Kryukov victor.kryukov@gmail.com writes:
Hello group,
when I'm trying to asdf-load hunchentoot 0.15 in clisp 2.41[2], I'm receiving the following error message[1].
The problem is that Luís Oliveira's name in two files, port-clisp.lisp and unix-clisp.lisp, is encoded with latin-1, while clisp expects utf-8, as explained here[3].
BTW, his name spelling is inconsistent in these two files, and according to [4], Luís Oliveira is the right one.
My patch to fix that behaviour is below[5] (it fixes the issue for clisp and hunchentoot still compiles on SBCL) - I basically saved both files in utf-8 and changes Luís' name spelling in port-clisp.lisp - although I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.
Regards, Victor.
[1] Error message:
;; Compiling file /home/victor/src/clbuild/source/hunchentoot/port-clisp.lisp ... *** - invalid byte sequence #xED #x76 #x65 in CHARSET:UTF-8 conversion The following restarts are available: RETRY :R1 Retry performing #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x000333DCB850>. ACCEPT :R2 Continue, treating #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x000333DCB850> as having been successful. ABORT :R3 ABORT Break 1 [2]>
[2] clisp --version
victor@esculap:~/src/clbuild/source/hunchentoot$ clisp --version GNU CLISP 2.41 (2006-10-13) (built on victor-desktop [127.0.1.1]) Software: GNU C 4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2) /usr/bin/gcc-4.1 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -x none libcharset.a libavcall.a libcallback.a /usr/lib/libreadline.so -lncurses -ldl -L/usr/lib -lsigsegv SAFETY=0 TYPECODES WIDE GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.4 libreadline 5.2 Features: (ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER CLX-ANSI-COMMON-LISP CLX READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) C Modules: (clisp i18n syscalls regexp readline linux clx) Installation directory: /usr/lib/clisp/ User language: ENGLISH Machine: X86_64 (X86_64) esculap.gateway.2wire.net [192.168.1.73]
[3] http://objectmix.com/lisp/339187-unicode-file-clisp.html
[4] http://www.cl-user.net/asp/l1-A5/sdataQ0So-oWAO7WqDQ3XMHpX8yBX8yBXnMq=/sdata...
[5]
diff -rN -u old-hunchentoot/port-clisp.lisp new-hunchentoot/port-clisp.lisp --- old-hunchentoot/port-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 +++ new-hunchentoot/port-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 @@ -1,7 +1,7 @@ ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*- ;;; $Header: /usr/local/cvsrep/hunchentoot/port-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
-;;; Copyright (c) 2006, Luis Olíveira loliveira@common-lisp.net. +;;; Copyright (c) 2006, LuÃs Oliveira loliveira@common-lisp.net. ;;; Copyright (c) 2007, Anton Vodonosov avodonosov@yandex.ru. ;;; Copyright (c) 2007, Dr. Edmund Weitz. ;;; All rights reserved. diff -rN -u old-hunchentoot/unix-clisp.lisp new-hunchentoot/unix-clisp.lisp --- old-hunchentoot/unix-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 +++ new-hunchentoot/unix-clisp.lisp 2008-02-06 00:07:40.000000000 -0600 @@ -1,7 +1,7 @@ ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*- ;;; $Header: /usr/local/cvsrep/hunchentoot/unix-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
-;;; Copyright (c) 2006, Luís Oliveira loliveira@common-lisp.net. +;;; Copyright (c) 2006, LuÃs Oliveira loliveira@common-lisp.net. ;;; Copyright (c) 2007, Anton Vodonosov avodonosov@yandex.ru. ;;; Copyright (c) 2007, Dr. Edmund Weitz. ;;; All rights reserved.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 06 Feb 2008 23:59:40 +0200, Anton Vodonosov avodonosov@yandex.ru wrote:
Transliteration to latin characters may make sense here, as it was originally done by Luís: http://common-lisp.net/~loliveira/patches/serve-event.diff.
But the accented "i" in his name /is/ a Latin character... :)
Edi Weitz edi@agharta.de writes:
On Wed, 06 Feb 2008 23:59:40 +0200, Anton Vodonosov avodonosov@yandex.ru wrote:
Transliteration to latin characters may make sense here, as it was originally done by Luís: http://common-lisp.net/~loliveira/patches/serve-event.diff.
But the accented "i" in his name /is/ a Latin character... :)
I thought latins didn't use characters above 7f...
On Wed, 06 Feb 2008 00:20:36 -0600, Victor Kryukov victor.kryukov@gmail.com wrote:
BTW, his name spelling is inconsistent in these two files, and according to [4], Luís Oliveira is the right one.
Thanks, I'll fix that.
My patch to fix that behaviour is below[5] (it fixes the issue for clisp and hunchentoot still compiles on SBCL) - I basically saved both files in utf-8 and changes Luís' name spelling in port-clisp.lisp - although I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.
Thanks for the patch, but I won't change the file format to UTF-8 as it'll make editing the files harder for me and I see no particular reason why text files should be assumed to be encoded in UTF-8 by default. (Not to mention that CLISP isn't even fully supported.)
What we can do to fix this is:
1. Change the name to simply "Luis Oliveira" if that's OK with Luís.
2. Add an encoding declaration (an Emacs file local variable) for ISO-8859-1 in the first line of the file. LispWorks, for example, will observe that. Don't know about CLISP.
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
On Wed, 06 Feb 2008 00:20:36 -0600, Victor Kryukov victor.kryukov@gmail.com wrote:
My patch to fix that behaviour is below[5] (it fixes the issue for clisp and hunchentoot still compiles on SBCL) - I basically saved both files in utf-8 and changes Luís' name spelling in port-clisp.lisp - although I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.
Thanks for the patch, but I won't change the file format to UTF-8 as it'll make editing the files harder for me and I see no particular reason why text files should be assumed to be encoded in UTF-8 by default. (Not to mention that CLISP isn't even fully supported.)
Sure, I'm not telling this is the best solution - it worked for me, but may not work for everybody.
BTW, why is editing UTF-8 files hard? Emacs is handling that pretty easily, and I'm sure LispWorks/Allegro IDEs should respect encodings as well.
What we can do to fix this is:
Change the name to simply "Luis Oliveira" if that's OK with Luís.
Add an encoding declaration (an Emacs file local variable) for ISO-8859-1 in the first line of the file. LispWorks, for example, will observe that. Don't know about CLISP.
It seems that CLISP doesn't support the 2 - otherwise Pascal wouldn't create his own library, I guess.[1]
Regards, Victor.
[1] http://groups.google.com/group/comp.lang.lisp/msg/815295c8ae5ab187
On Wed, 06 Feb 2008 18:16:17 -0600, Victor Kryukov victor.kryukov@gmail.com wrote:
BTW, why is editing UTF-8 files hard? Emacs is handling that pretty easily, and I'm sure LispWorks/Allegro IDEs should respect encodings as well.
They do, but they have to open otherwise unknown text files with some default encoding which in my case is Latin 1. (And that makes sense as almost all text files I'm dealing with are Latin 1.) But it seems CLISP doesn't:
It seems that CLISP doesn't support the 2
otherwise Pascal wouldn't create his own library, I guess.
I wouldn't be so sure about that. My impression from c.l.l is that Pascal B. often starts to hack already when he should still think about the problem... :)
Edi Weitz edi@agharta.de writes:
- Change the name to simply "Luis Oliveira" if that's OK with Luís.
That's what I do in most of my source code to avoid encoding issues.
-
Anton Vodonosov -
Edi Weitz -
Luis Oliveira -
Mostafa Razavi -
Nico de Jager -
Victor Kryukov -
Zach Beane