kc3-lang/libevent/whatsnew-2.2.txt

• Show log

  Commit

• Hash : 8dcb94a4
  Author :
  Date : 2016-01-08T13:36:20
  

  Added http method extending
  
  User can define his own response method by calling
  evhttp_set_ext_method_cmp() on the struct http, or
  evhttp_connection_set_ext_method_cmp() on the connection.
  
  We expose a new stucture `evhttp_ext_method` which is passed to the
  callback if it's set. So any field can be modified, with some exceptions
  (in evhttp_method_):
  
  If the cmp function is set, it has the ability to modify method, and
  flags. Other fields will be ignored. Flags returned are OR'd with the
  current flags.
  
  Based on changes to the #282 from: Mark Ellzey <socket@gmail.com>
  

Download

• whatsnew-2.2.txt

• ...
  
  * Building libevent as a sub-project using GNU Auto* tools
  
  Some projects will choose to include libevent in their source distribution,
  and build libevent as a sub-project.  This may be effected by putting the
  line:
  
   AC_CONFIG_SUBDIRS([path/to/libevent])
  
  in the master configure.ac file for the master project.
  
  There are cases where the master project will want to pass in additional
  flags for CFLAGS, CPPFLAGS, or LDFLAGS.  Since these variables are reserved
  for the user, and AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS are reserved for
  each package, libevent offers the following variables for a master package
  to tell libevent that there are additional compile/link values:
  
   LIBEVENT_CFLAGS
   LIBEVENT_CPPFLAGS
   LIBEVENT_LDFLAGS
  
  A master package can set these variables in its configure.ac file.
  
  Here's an example:
  
  configure.ac:
  ...
  EXTRA_CFLAGS=...
  EXTRA_CPPFLAGS=...
  EXTRA_LDFLAGS=...
  ...
  dnl ac_configure_args is undocumented but widely abused, as here,
  dnl to modify the defaults of the libevent subpackage, by prefixing
  dnl our changes to the child configure arguments already assembled.
  dnl User-supplied contradictory choices should prevail thanks to
  dnl "last wins".
  ac_configure_args=" --disable-openssl${ac_configure_args}"
  ac_configure_args=" --disable-shared${ac_configure_args}"
  ac_configure_args=" --disable-libevent-regress${ac_configure_args}"
  ac_configure_args=" --disable-libevent-install${ac_configure_args}"
  ac_configure_args=" --enable-silent-rules${ac_configure_args}"
  ac_configure_args=" --enable-function-sections${ac_configure_args}"
  ac_configure_args=" LIBEVENT_CFLAGS='${EXTRA_CFLAGS}'${ac_configure_args}"
  ac_configure_args=" LIBEVENT_CPPFLAGS='${EXTRA_CPPFLAGS}'${ac_configure_args}"
  ac_configure_args=" LIBEVENT_LDFLAGS='${EXTRA_LDFLAGS}'${ac_configure_args}"
  AC_CONFIG_SUBDIRS([libevent])
  ...
  
  The space after the initial '"' is significant.
  
  * "Prepare" and "check" watchers
  
  Libevent now has a new mechanism for hooking into the event loop: "prepare" and
  "check" watchers.  A "prepare" watcher is a callback that fires immediately
  before polling for I/O. A "check" watcher is a callback that fires immediately
  after polling and before processing any active events. This may be useful for
  embedding other libraries' event loops (e.g. UI toolkits) into libevent's. It's
  also useful for monitoring server performance. For example, if you measure the
  time between "prepare" and "check," that is the polling duration; the difference
  between the expected and actual polling duration provides an indication of
  kernel scheduling delay. And if you measure the time between "check" and the
  next "prepare" (in the next iteration of the event loop), that is a good
  approximation of the amount of time handling events; this provides a convenient
  way to monitor whether any event handlers are blocking or otherwise performing
  heavy computation.
  
  The watcher API is defined in <event2/watch.h>. A concrete example of how
  watchers can help monitor server performance is available in
  "sample/watch-timing.c".
  
  * Support for custom HTTP methods
  
  Libevent HTTP code now supports defining custom HTTP methods. It is done
  through a callback:
  
    #define EVHTTP_REQ_CUSTOM      ((EVHTTP_REQ_MAX) << 1)
    static int ext_method_cb(struct evhttp_ext_method *p)
    {
      if (p == NULL)
        return -1;
      if (p->method) {
        if (strcmp(p->method, "CUSTOM") == 0) {
          p->type = EVHTTP_REQ_CUSTOM;
          p->flags = 0;   /*EVHTTP_METHOD_HAS_BODY*/
          return 0;
        }
      } else {
        if (p->type == EVHTTP_REQ_CUSTOM) {
          p->method = "CUSTOM";
          return 0;
        }
      }
    }
  
  And to register this callback with http server you can use:
    evhttp_set_ext_method_cmp(http, ext_method_cb);
  
  Or registering callback with one client only:
    evhttp_connection_set_ext_method_cmp(evcon, ext_method_cb);
  

Download