[Libevent-users] [PATCH] remove useless argument in bufferevent_read_pressure_cb
Hello,
In bufferevent_read_pressure_cb() function, the second argument (which
is size_t old) is not used. Here's a patch which removes it.
Regards,
Charles Longeau
Index: trunk/libevent/evbuffer.c
===
--- trunk/libevent/evbuffer.c (revision 502)
+++ trunk/libevent/evbuffer.c (working copy)
@@ -53,7 +53,7 @@
/* prototypes */
void bufferevent_setwatermark(struct bufferevent *, short, size_t, size_t);
-void bufferevent_read_pressure_cb(struct evbuffer *, size_t, size_t, void *);
+void bufferevent_read_pressure_cb(struct evbuffer *, size_t, void *);
static int
bufferevent_add(struct event *ev, int timeout)
@@ -75,8 +75,8 @@
*/
void
-bufferevent_read_pressure_cb(struct evbuffer *buf, size_t old, size_t now,
-void *arg) {
+bufferevent_read_pressure_cb(struct evbuffer *buf, size_t now, void *arg)
+{
struct bufferevent *bufev = arg;
/*
* If we are below the watermark then reschedule reading if it's
@@ -401,7 +401,7 @@
/* If the watermarks changed then see if we should call read again */
bufferevent_read_pressure_cb(bufev-input,
- 0, EVBUFFER_LENGTH(bufev-input), bufev);
+ EVBUFFER_LENGTH(bufev-input), bufev);
}
int
Index: trunk/libevent/buffer.c
===
--- trunk/libevent/buffer.c (revision 502)
+++ trunk/libevent/buffer.c (working copy)
@@ -116,9 +116,9 @@
* of data that we transfered from inbuf to outbuf
*/
if (inbuf-off != oldoff inbuf-cb != NULL)
- (*inbuf-cb)(inbuf, oldoff, inbuf-off, inbuf-cbarg);
+ (*inbuf-cb)(inbuf, inbuf-off, inbuf-cbarg);
if (oldoff outbuf-cb != NULL)
- (*outbuf-cb)(outbuf, 0, oldoff, outbuf-cbarg);
+ (*outbuf-cb)(outbuf, oldoff, outbuf-cbarg);
return (0);
}
@@ -137,7 +137,6 @@
{
char *buffer;
size_t space;
- size_t oldoff = buf-off;
int sz;
va_list aq;
@@ -168,7 +167,7 @@
if (sz space) {
buf-off += sz;
if (buf-cb != NULL)
- (*buf-cb)(buf, oldoff, buf-off, buf-cbarg);
+ (*buf-cb)(buf, buf-off, buf-cbarg);
return (sz);
}
if (evbuffer_expand(buf, sz + 1) == -1)
@@ -305,7 +304,6 @@
evbuffer_add(struct evbuffer *buf, const void *data, size_t datlen)
{
size_t need = buf-misalign + buf-off + datlen;
- size_t oldoff = buf-off;
if (buf-totallen need) {
if (evbuffer_expand(buf, datlen) == -1)
@@ -316,7 +314,7 @@
buf-off += datlen;
if (datlen buf-cb != NULL)
- (*buf-cb)(buf, oldoff, buf-off, buf-cbarg);
+ (*buf-cb)(buf, buf-off, buf-cbarg);
return (0);
}
@@ -341,7 +339,7 @@
done:
/* Tell someone about changes in this buffer */
if (buf-off != oldoff buf-cb != NULL)
- (*buf-cb)(buf, oldoff, buf-off, buf-cbarg);
+ (*buf-cb)(buf, buf-off, buf-cbarg);
}
@@ -404,7 +402,7 @@
/* Tell someone about changes in this buffer */
if (buf-off != oldoff buf-cb != NULL)
- (*buf-cb)(buf, oldoff, buf-off, buf-cbarg);
+ (*buf-cb)(buf, buf-off, buf-cbarg);
return (n);
}
@@ -447,7 +445,7 @@
}
void evbuffer_setcb(struct evbuffer *buffer,
-void (*cb)(struct evbuffer *, size_t, size_t, void *),
+void (*cb)(struct evbuffer *, size_t, void *),
void *cbarg)
{
buffer-cb = cb;
Index: trunk/libevent/event.h
===
--- trunk/libevent/event.h (revision 502)
+++ trunk/libevent/event.h (working copy)
@@ -660,7 +660,7 @@
size_t totallen;
size_t off;
- void (*cb)(struct evbuffer *, size_t, size_t, void *);
+ void (*cb)(struct evbuffer *, size_t, void *);
void *cbarg;
};
@@ -997,7 +997,7 @@
@param cb the callback function to invoke when the evbuffer is modified
@param cbarg an argument to be provided to the callback function
*/
-void evbuffer_setcb(struct evbuffer *, void (*)(struct evbuffer *, size_t,
size_t, void *), void *);
+void evbuffer_setcb(struct evbuffer *, void (*)(struct evbuffer *, size_t,
void *), void *);
/*
* Marshaling tagged data - We assume that all tags are inserted in their
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] [OT] craigslist: libevent programmer wanted
http://sfbay.craigslist.org/pen/cpg/472325599.html libevent programmer wanted (san mateo) Reply to: [EMAIL PROTECTED] Date: 2007-11-07, 8:33PM PST I'm guessing if you clicked on this link, you probably know what libevent is, and you're probably more than proficient in C. I have a small project for someone who has previous experience with libevent, and _understands_ HTTP (not just what it is, but has good experience on the protocol layer). The project is to build a blazingly fast HTTP client for lots of parallel requests. Here is a short description: *Build a daemon with libevent that: 1. watches a directory called request 2. when a new file arrives in request, load the file (format below) 3. augment the content with the appropriate headers 4. makes the HTTP request 5. upon success, write the contents of the response to a file of the same name, in a directory called result 6. upon failure, write an error message to a file of the same name, in a directory called error *The program should: - be written in C - use libevent for filesystem events - use libevent for the HTTP request event loop - support most of HTTP/1.1, especially chunking - allow at least 5000 concurrent requests without breaking a sweat - NOT BLOCK ON ANY STEP *File format: hostname http headers http body EOF *Example file: www.monkey.org POST /banana HTTP/1.1 Content-Type: text/xml ?xml version=1.0 ? monkey foodbanana/food /monkey EOF By the way, someone already has a good start on this in a image grabbing program called crawl (http://monkey.org/~provos/crawl/). If anyone is up to this, please send me an email and tell me what you want in terms of compensation. Thanks! ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] remove useless argument in bufferevent_read_pressure_cb
On Thu, Nov 08, 2007 at 11:05:27AM +0100, Charles Longeau wrote: Hello, In bufferevent_read_pressure_cb() function, the second argument (which is size_t old) is not used. Here's a patch which removes it. Hi, Charles! bufferevent_read_pressure_cb() may not use the second argument, but other users of the evbuffer API can and likely do. (The evbuffer API is, after all, exported in event.h.) I don't want to break existing code if I can help it. yrs, -- Nick Mathewson pgpd6GCXYCiDt.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libev-1.3e demo release - small u_char event_active() issues
On Fri, Nov 09, 2007 at 12:47:03AM +0100, Chris Brody-GMail [EMAIL PROTECTED] wrote: First, when I built on OSX, u_char was not defined in event.c. I fixed this problem by #include sys/types.h before ev.h event.h. Hmm, u_char is not used by anything in libev itself, but it is defined in event_compat.h, which should get included. Oh right, it only defines it on win32 and assumes its there on all other systems. I think I will include a typedef for it unconditionally in event_compat.h. Thanks for pointing this out! (googling around, this seems to be an already-known bug in libevent-1.3e, so I guess I wait till a new release comes out with a fix for this). Its there now (I updated the tarball), the libev equivalent is ev_feed_event. I don't really feel well about exposing it, though, without actually having a use case that isn't served better by simply calling the callback immediatelly. Small problem with MULTIPLICITY-apparently forgot dLOOPev some EV_A_ defs. Oh indeed, sorry. I replaced the tarball after adding the new functions without testing them with mulcitplicity defined. Its been updated by now (including a temporary include sys/types.h in event_compat.h, whivch shouldn't hurt, although sys/types.h is not really required to support u_char in the first place, afaicr). Given the patch below, I was able to build and run the regression Sorry for having you go through the code and add this. The patch is just perfect :) tests on OSX. In addition, all test from eventxx were working except for bench.cpp, which uses a strange copy constructor, Do you have a pointer to the source? and priority test. thats expected indeed. Thanks a lot for testing! The tarball at http://data.plan9.de/libev-1.3e.tar.gz has been updated with everything that came up so far. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [OT] craigslist: libevent programmer wanted
Hi! On Thu, Nov 08, 2007 at 02:19:25PM -0800, Christopher Layne wrote: On Thu, Nov 08, 2007 at 08:11:55AM -0800, Garth Patil wrote: http://sfbay.craigslist.org/pen/cpg/472325599.html libevent programmer wanted (san mateo) - NOT BLOCK ON ANY STEP close() can block. *boom tsst*. On sockets, IIRC only with non-standard settings of the SO_LINGER option. The setsockopt(4) manual page, on OpenBSD, says: SO_LINGER controls the action taken when unsent messages are queued on socket and a close(2) is performed. If the socket promises reliable de- livery of data and SO_LINGER is set, the system will block the process on the close(2) attempt until it is able to transmit the data or until it decides it is unable to deliver the information (a timeout period mea- sured in seconds, termed the linger interval, is specified in the setsockopt() call when SO_LINGER is requested). If SO_LINGER is disabled and a close(2) is issued, the system will process the close in a manner that allows the process to continue as quickly as possible. And IIRC, SO_LINGER *is* disabled by default. So if you want close not to block, you either keep SO_LINGER disabled or set the linger timeout to zero (which specifies *different* behaviors!). And then, for HTTP, this should be relatively irrelevant, as usually the client (and the task specified was a HTTP *client*, not a server) closes the connection only after receiving the response, and the server even only *starts* sending the response after having received the whole request, so the transmit buffer of the socket should be empty anyway when the client closes the socket. Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libev-1.3e demo release
On Thu, Nov 08, 2007 at 03:03:40PM -0500, Nick Mathewson [EMAIL PROTECTED] wrote: - You probably want event.h to include event_compat.h inside angle brackets, not inside quotes. Its not in fact a problem with embedding as EV_STANDALONE prevents it from being included anyways (so its just a well spotted :). It is a problem with ev.h, though. - There's no event_active compatibility function defined. I looked Its there now (I updated the tarball), the libev equivalent is ev_feed_event. I don't really feel well about exposing it, though, without actually having a use case that isn't served better by simply calling the callback immediatelly. Internally, it queues the event into the pending list by separating on the three principal signal sources (EV_TIMEOUT or EV_READ/WRITE or EV_SIGNAL), but that could likely be improved. (Incidentally, ncalls is also being ignored this way, but as others found it, its not a very useful feature of libevent. I atcually wanted to provide something like this for repeating timers, as I found that event loops either do the wrong thing (call hard-realtime-scheduled timers in a loop for each skipped tick) or do the wrong thing (not telling the app how many ticks were being skipped), but none of the timer types in libev have a sensible definition for it). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] remove useless argument in bufferevent_read_pressure_cb
On Thu, Nov 08, 2007 at 09:15:18PM +0100, Charles Longeau wrote: Hi, bufferevent_read_pressure_cb() may not use the second argument, but other users of the evbuffer API can and likely do. (The evbuffer API is, after all, exported in event.h.) I don't want to break existing code if I can help it. I understand that breaking existing API is not a good solution. However, we can still avoid passing unneeded arguments to bufferevent_read_pressure_cb. Here's an updated patch which removes unneeded arguments without breaking the evbuffer API. I'm afraid that will still break existing code. Any applications that are using evbuffer will expect to get the old buffer size passed to their callback. For example, they may want to know how much data was just added to the buffer. If they get 0 instead of the original buffer length, they will compute an incorrect answer for how much data was just added. yrs, -- Nick Mathewson pgpXTmdhoZ8Tt.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
