event handlers not working

I'm trying to write a simple example. But I cannot make the event
handler work. Could you please check this code (mostly stolen from
philip-jose).

(in-package :asdf)

(defpackage :iolib-test
  (:use #:common-lisp #:net.sockets #:iomux #:bordeaux-threads))

(in-package :iolib-test)

(defparameter *server* nil)
(defparameter *event-base* (make-instance 'iomux:event-base))
(defparameter *server-event* nil)

(defun handle-connection (sock handler)
  (unwind-protect
       (progn
         (apply handler sock)
         (finish-output sock))
    (close sock)))

(defun make-server (port)
  (let ((sock (make-socket :address-family
                           :internet
                           :type
                           :stream
                           :connect
                           :passive
                           :ipv6 nil)))

Re: event handlers not working

On Fri, Jun 01, 2007 at 01:40:55PM +0300, Aycan iRiCAN wrote:
>I'm trying to write a simple example. But I cannot make the event
>handler work. Could you please check this code (mostly stolen from
>philip-jose).
you forgot to run the event loop :)
I've attached a slightly modified version of the code

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")

;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp -*-

(in-package :common-lisp-user)

(defpackage :iolib-test
  (:use #:common-lisp #:net.sockets #:iomux #:bordeaux-threads))

(in-package :iolib-test)

(defvar *server*)
(defvar *event-base* (make-instance 'iomux:event-base))
(defvar *event-loop-thread*)
(defvar *server-event*)

(defun handle-connection (sock handler)
  (unwind-protect
       (progn
         (funcall handler sock)

Re: event handlers not working

On Fri, Jun 01, 2007 at 03:21:16PM +0200, Stelian Ionescu wrote:
>On Fri, Jun 01, 2007 at 01:40:55PM +0300, Aycan iRiCAN wrote:
>>I'm trying to write a simple example. But I cannot make the event
>>handler work. Could you please check this code (mostly stolen from
>>philip-jose).
>you forgot to run the event loop :)
>I've attached a slightly modified version of the code
I forgot to say that you'll need the live sources of iolib-posix and iolib,
although I'll soon make a new release
see http://common-lisp.net/project/iolib/download.shtml

--

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")

_______________________________________________
iolib-devel mailing list
iolib-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel

New releases: iolib-posix-0.5.4 and iolib-0.5.3

I've just made a new round of releases.
Changes WRT the previous version are:

* NET.SOCKETS: TCP socket options for Linux and FreeBSD have been added,
  so now you can set options like TCP_MAXSEG and TCP_NODELAY

* NET.SOCKETS: calling BIND-ADDRESS on active sockets now works,
  although probably it is seldom needed

* NET.SOCKETS: the function MAKE-SOCKET have been renamed to
  CREATE-SOCKET, and an implementation of MAKE-SOCKET compatible with
  Allegro 8 has been added basically you can now do something like this:
  (make-socket :address-family :internet :type :stream
               :connect :passive :reuse-address t
               :local-host host :local-port port)

* NET.SOCKETS: it is now possible to specify an active socket's external
  format in MAKE-SOCKET and setting it through (SETF EXTERNAL-FORMAT-OF)
  works better; accepted values are:
    - keywords: either :default or the name of an encoding, :utf-8 or
      :ascii for instance
    - lists specifying the encoding and the end-of-line flavour(:unix,
      :mac or :dos): '(:utf-8 :line-terminator :dos)
    - EXTERNAL-FORMAT structures, as returned by IOENC:MAKE-EXTERNAL-FORMAT

* a modified version of CL-SMTP has been added in package NET.SMTP-CLIENT
  the system depends on CL-BASE64 and has only one external symbol: the
  function SEND-EMAIL

* NET.SOCKETS: the INVALID-ADDRESS condition has been eliminated, the address

crash with the current iolib

Hi,

First I want to thank you for your great effort. I tried to stress the
current iolib. Attached is a simple HTTP reply generator. I used sbcl
1.0.5 VM on a 32 bit AMD desktop machine. I used siege with lot's of
concurrent connections. Here is the first inspection:

This is my stupid test server with current iolib (with a small content
size).

aycan <at> zen ~ $ siege -b -c10 -t5S http://localhost:8001/
** siege 2.61
** Preparing 10 concurrent users for battle.
The server is now under siege...
Lifting the server siege..      done.
Transactions:                   6996 hits
Availability:                 100.00 %
Elapsed time:                   4.86 secs
Data transferred:             615648 bytes
Response time:                  0.01 secs
Transaction rate:            1439.51 trans/sec
Throughput:                126676.54 bytes/sec
Concurrency:                    9.53
Successful transactions:        6996
Failed transactions:               0
Longest transaction:            4.25
Shortest transaction:           0.00

I got 1490 transactions per second. The performance is great (I got
around 500 trans/sec with a threaded version) but when I repeat the

Re: crash with the current iolib

On Mon, Jun 04, 2007 at 01:04:13PM +0300, Aycan iRiCAN wrote:
>Hi,
>
>First I want to thank you for your great effort. I tried to stress the
>current iolib. Attached is a simple HTTP reply generator. I used sbcl
>1.0.5 VM on a 32 bit AMD desktop machine. I used siege with lot's of
>concurrent connections. Here is the first inspection:
I've attached your code which I modified a bit in order to be able to
debug it more easily

>I got 1490 transactions per second. The performance is great (I got
>around 500 trans/sec with a threaded version) but when I repeat the
>test, SBCL crashes silently and eats all my cpu. I don't get any errors
>or some output.
it crashes here too with the latest SBCL, with a memory-fault-error(most
of the time, I also got various types of heap corruption) - I had to
run SBCL directly from the terminal because indeed Slime seems not to be
able to cope with a memory fault in the REPL thread. On my computer SBCL
crashed directly if I run the test for just 7 seconds
I've also tried CMUCL which is a bit sturdier(but essentially it crashes
too), while CLISP had no problems(although it is slower that SBCL or CMUCL):

hechee <at> blackhole iolib $ siege -b -c10 -t400S http://localhost:8001/
** siege 2.65
** Preparing 10 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
Transactions:		      216139 hits
Availability:		      100.00 %
Elapsed time:		      400.81 secs

Bug in asdf-additions-0.5.2: lispworks spell wrong

Hi, iolib developers

There's a small bug in asdf-additions-0.5.2: you spell "lispworks" to
"lisworks", this caused cannot compile iolib in LispWorks, actually
didn't start.

A trivial patch in attach.

Chun Tian (binghe)

_______________________________________________
iolib-devel mailing list
iolib-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel

Re: Bug in asdf-additions-0.5.2: lispworks spell wrong

On Thu, Jun 07, 2007 at 01:19:29AM +0800, Chun Tian (binghe) wrote:
>Hi, iolib developers
>
>There's a small bug in asdf-additions-0.5.2: you spell "lispworks" to
>"lisworks", this caused cannot compile iolib in LispWorks, actually
>didn't start.
>
>A trivial patch in attach.
thanks, fixed :)
plase remember though to send unified diffs next time because they're
much easier to read

--

-- 
(sign :name "Stelian Ionescu" :aka "fe[nl]ix"
      :quote "Quidquid latine dictum sit, altum videtur.")

_______________________________________________
iolib-devel mailing list
iolib-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel

(gcc-cpu-flags) in asdf-additions/unix-dso.lisp

_______________________________________________
iolib-devel mailing list
iolib-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/iolib-devel

Re: (gcc-cpu-flags) in asdf-additions/unix-dso.lisp

Wrong wrong wrong!

The -m32 or -m64 are both needed, because you may be running on a
machine where the default distribution is of one type, but your Lisp
process is of a different size!

Here at ITA, we casually compile 32-bit Lisp executable on 64-bit
machines, and the reverse is not unconceivable either.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
When everything seems to be going against you, remember that the airplane takes
off against the wind, not with it. -- Henry Ford

On 06/06/07, Chun Tian <binghe.lisp <at> gmail.com> wrote:
> Hi, iolib developers
>
> I'm not sure why need a (gcc-cpu-flags) function to detect a gcc compile
> flag (-m32/-m64) and use this to compile C files.
>
> First, use (cffi:foreign-type-size :int) to guess is wrong at least on
>
> amd64 Linux: (cffi:foreign-type-size :int) return 4 on amd64 Linux, so
> you guess wrong to 32-bit.
>
> Second, if you guess wrong, a 64-bit Lisp process will can not load a
> 32-bit library.
>
> If I disable this (gcc-cpu-flags), gcc with no -m32/-m64 can always do
>
> the right thing on both 32 and 64-bit platform, and the Lisp process can
> load this library. (I'm just doing this on Debian GNU/Linux amd64 and
> LispWorks 5.0.2 Enterprise Edition for AMD64 Linux.) Am I right?