mirror of
https://github.com/libevent/libevent.git
synced 2025-01-09 00:56:20 +08:00
8dcb94a4ca
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>
101 lines
3.8 KiB
Plaintext
101 lines
3.8 KiB
Plaintext
...
|
|
|
|
* 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);
|