On COMET w/ hunchentoot: http://common-lisp.net/pipermail/tbnl-devel/2009-February/004620.html

I have a working comet system using Hunchentoot.

The basic way I'm operating is to have the browser contact the hunchentoot
server and the server thread waits on a semaphore. Any other thread can then
release the semaphore and cause a reply back to the browser.

Hope this helps. I am only using this for development purposes, as I have
been having problems with certain browsers, and this will also occupy one of
the available browser requests, where many browsers have a very small number
available.

(defun kill-comet-thread (thread)
  (warn "KILLING COMET THREAD: ~a" thread)
  (ignore-errors
    (destroy-thread thread)))

(defun handle-comet ()
  (awhen (session-value 'comet-thread) (kill-comet-thread it))
  (setf (session-value 'comet-thread) *current-thread*)
  (wait-on-semaphore (session-value 'comet-semaphore))
  (setf (session-value 'comet-thread) nil)
  (aif (session-value 'comet-fn) (funcall it)))

(defun comet (fn &optional (session *working-session*))
  (setf (session-value 'comet-fn session) fn)
  (signal-semaphore (session-value 'comet-semaphore session)))

--------------------------------------------------------------------------------

Empire connection handling

Maybe do something like cl-irc does with register/unregister handler. Might be
even better combined with the modes system, provide an easy way to specify which
event types a specific mode implementation is interested in. Register automatically
on construction and deregister when leaving the mode.

Using the object system like I do it right doesn't seem like a really good fit.