libevent2

Notices and updates
Locked
Jeff
Posts: 604
Joined: Sat Apr 07, 2007 2:23 pm
Location: Ohio
Contact:

libevent2

Post by Jeff »

Howdy folks. Haven't been around in a while. Wanted to let you know that I put together a wrapper for libevent2 using the new FFI features. Made it very easy. You can find it on github here - https://github.com/jsober/nl-event.
Jeff
=====
Old programmers don't die. They just parse on...

Artful code

cormullion
Posts: 2038
Joined: Tue Nov 29, 2005 8:28 pm
Location: latiitude 50N longitude 3W
Contact:

Re: libevent2

Post by cormullion »

Hi Jeff. It has indeed been a while - glad to see you've not forgotten anything!

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: libevent2

Post by Lutz »

The libevent2 module is also available here:

http://www.newlisp.org/modules/various/ ... 2.lsp.html

... and I added a location link back to github

jopython
Posts: 123
Joined: Tue Sep 14, 2010 3:08 pm

Re: libevent2

Post by jopython »

I wonder what this means for newLisp?
Does this mean we don't have to spawn a separate newlisp process for each http request because we have events?

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: libevent2

Post by Lutz »

No different processes are required, newLISP could execute another function while waiting for the callback. The callback will interrupt current processing and execute the callback function. After the callback function finished, the interrupted one will continue.

Jeff
Posts: 604
Joined: Sat Apr 07, 2007 2:23 pm
Location: Ohio
Contact:

Re: libevent2

Post by Jeff »

Actually, that is not exactly true. That is more how signals work, although not in libevent. In libevent, the application is controlled by the loop. Before starting the loop, you register at least one socket or timer to run in it. It is an error to run a loop with no events registered.

For example, to implement a server, you would register the listening socket. When a remote client connects, your registered callback is triggered. You accept the new connection, creating a new socket, and register an event handler for that socket as well. When it sends a request, your handler is triggered with a read event. Your app determines its response, which it sends on the next write event.

At no point does execution yield. If your server takes a long time to build a response to a request, the entire application will block. This is where multiple processes might be used, allowing the server process to continue to service clients while child processes do the work of interpreting requests and generating responses.
Jeff
=====
Old programmers don't die. They just parse on...

Artful code

Jeff
Posts: 604
Joined: Sat Apr 07, 2007 2:23 pm
Location: Ohio
Contact:

Re: libevent2

Post by Jeff »

Here is an example of how a simple echo server might look:

Code: Select all

(load "libevent2.lsp")

(setf listen (net-listen 8000))

(unless listen
  (throw-error (net-error)))

(libevent:init)
(libevent:watch listen libevent:READ
  (lambda (fd e id , client)
    ; accept a new connection
    (setf client (net-accept listen))

    ; watch for requests
    (libevent:watch client libevent:READ
      (lambda (fd e id , req)
        ; read request
        (setf req (read-line fd))

        ; On a real server, here is where you would process the request,
        ; most likely in a secondary process. In that case, you would execute
        ; the code below when it finished, rather than immediately after
        ; the request comes in.

        ; wait for client to be ready to accept a response
        (libevent:watch-once client libevent:WRITE
          (lambda (fd e id)
            ; send response
            (write fd req)))))))

(libevent:run)
A real server would have to watch for timeouts, disconnects, etc., as well, but this gives you the basic idea.
Jeff
=====
Old programmers don't die. They just parse on...

Artful code

Locked