headers
Phil Budne | 7 May 2008 03:52
Favicon

patch to libevent 1.3e rtsig.c

The ChangeLog file mentioned that rtsig support was removed in 1.40-beta:
    Changes in 1.4.0-beta:
    ....
    o Remove support for the rtsig method: it hasn't compiled for a while ...

With the patch against libevent 1.3e included below, rtsig.c compiles.

I only noticed that RT signals were supported because the 1.4.3 man
page had the (obsolete) note:
    Support for real-time signals is due to Taral.

NOTE!

I have not yet tested it.  A client of mine is looking at converting
an application from RT signals to epoll, and I wanted to benchmark the
performance of the two mechanisms (no paper I've found covers both),
and libevent looked like a good way to test the two head on, and
perhaps the ideal new API to use).

Suggestions on testing/benchmarking methods would be most welcome
(ie; programs/scripts to generate graphs found on the libevent home page)!

Phil

*** rtsig.c.orig	2007-07-30 23:41:04.000000000 -0400
--- rtsig.c	2008-05-06 21:23:00.000000000 -0400
***************
*** 176,190 ****
  #include "event.h"
  #include "event-internal.h"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Lehmann | 7 May 2008 17:42
Picon
Favicon

FYI: libevent/libev benchmark updated for libevent-1.4.3

As version 1.4.3-stable of libevent uses a more efficient binary heap
over the red-black tree used before, the benchmark at:

  http://libev.schmorp.de/bench.html

was quite outdated. I therefore updated it by benchmarking libev-3.31 vs.
libevent-1.4.3.

The main difference is that the growth characteristics of libevent are now
similar to libev (and the factor of 2-3 remains).

(Note that the upcoming 3.33 version of libev uses a more cache-friendly
4-heap, but the benchmark still uses 3.31).

Enjoy,

--

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg <at> goof.com
      -=====/_/_//_/\_,_/ /_/\_\
Permalink | Reply | 7 comments |
headers
Dan | 8 May 2008 07:03
Favicon

Re: FYI: libevent/libev benchmark updated for libevent-1.4.3


Think I tried Ev once, to many bugs, hell couldn't even set a timer within 
a timer as I remember, This EV stuff just meant to undermine the hardwork 
of the folks at libevent?

Dan.

On Wed, 7 May 2008, Marc Lehmann wrote:

> As version 1.4.3-stable of libevent uses a more efficient binary heap
> over the red-black tree used before, the benchmark at:
>
>  http://libev.schmorp.de/bench.html
>
> was quite outdated. I therefore updated it by benchmarking libev-3.31 vs.
> libevent-1.4.3.
>
> The main difference is that the growth characteristics of libevent are now
> similar to libev (and the factor of 2-3 remains).
>
> (Note that the upcoming 3.33 version of libev uses a more cache-friendly
> 4-heap, but the benchmark still uses 3.31).
>
> Enjoy,
>
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
(Continue reading)

Permalink | Reply | 5 comments |
headers
Manuel Simoni | 8 May 2008 08:31
Picon
Gravatar

Patch: useful sendfile for HTTP servers (1.4.3-stable)

[Resending because apparently it didn't get through yesterday.]

Hi,

my HTTP server thingy came to a screeching halt when serving many
large files, so I added a form of Linux sendfile support that requires
just a few changes and supports some interesting uses (e.g. sending
the HTTP headers normally but the HTTP body via sendfile).

The server now runs very fast, with very little CPU and RAM.  This is
preliminary, probably buggy, and I don't understand the evbuffer
functionality very well (e.g. draining).

In addition to the normal data evbuffers, this patch adds two types of
evbuffers: (1) sendfile buffers, and (2) data buffers to which a
sendfile buffer has been added.  This distinction is recorded in the
sf_fd field.  There are two additonal fields, sf_off and sf_buf.

*** libevent-1.4.3-stable/event.h       2008-02-23 02:36:12.000000000 +0100
--- libevent-1.4.3-stable-sendfile/event.h      2008-05-07
15:40:32.000000000 +0200
***************
*** 724,729 ****
--- 724,746 ----
        size_t totallen;
        size_t off;

+       /*
+         sf_fd == -1.  A standard data buffer.  sf_off and sf_buf are
+         unused.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Niels Provos | 8 May 2008 08:47
Picon
Favicon

Re: Patch: useful sendfile for HTTP servers (1.4.3-stable)

Hi Manual,

this is a good suggestion.   Nick and I are currently working on how
buffers and http work in libevent 2.0.  You might want to check out
trunk to see some of the progress there.   In any case, it seems that
your sendfile changes would be a good fit there.  BTW, sendfile is
available on a large number of platforms now.

Niels.

On Wed, May 7, 2008 at 11:31 PM, Manuel Simoni <msimoni <at> gmail.com> wrote:
> [Resending because apparently it didn't get through yesterday.]
>
>  Hi,
>
>  my HTTP server thingy came to a screeching halt when serving many
>  large files, so I added a form of Linux sendfile support that requires
>  just a few changes and supports some interesting uses (e.g. sending
>  the HTTP headers normally but the HTTP body via sendfile).
>
>  The server now runs very fast, with very little CPU and RAM.  This is
>  preliminary, probably buggy, and I don't understand the evbuffer
>  functionality very well (e.g. draining).
>
>
>  In addition to the normal data evbuffers, this patch adds two types of
>  evbuffers: (1) sendfile buffers, and (2) data buffers to which a
>  sendfile buffer has been added.  This distinction is recorded in the
>  sf_fd field.  There are two additonal fields, sf_off and sf_buf.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jass Zhao | 8 May 2008 12:00
Picon

Error of evsigcaught

 
Hi,
 
I ran into some problem when  I try to call event_init(). Not sure what the following evsigcaught value indicates? An error?
 
evsigcaught = {0, 0, 0, 0, 0, 0, 0, -1208486080, 0, 134305, 0 <repeats 55 times>}
 
Thanks,
Peng
_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 0 comments |
headers
Nick Mathewson | 8 May 2008 16:33

Re: Patch: useful sendfile for HTTP servers (1.4.3-stable)

On Wed, May 07, 2008 at 11:47:09PM -0700, Niels Provos wrote:
> Hi Manual,
> 
> this is a good suggestion.   Nick and I are currently working on how
> buffers and http work in libevent 2.0.  You might want to check out
> trunk to see some of the progress there.   In any case, it seems that
> your sendfile changes would be a good fit there.  BTW, sendfile is
> available on a large number of platforms now.

In fact, this fits pretty well into the newer evbuffer implementation.
Whereas the old implementation used a big chunk of memory for the
entire buffer, the new code uses a linked list of small chunks. (This
removes the need for big memmov operations, and generally makes
writing big files more efficient.)

All we'd need to do to support sendfile is add another chunk type
whose contents were a file rather than a chunk of ram.  We'd probably
want at least two ways to "add a file at this point in the stream":
one taking a filename and one taking an fd.  Of course, we'd need to
make sure to fall back on mmap() for systems lacking sendfile(), and
maybe on a series of read() operations on systems lacking mmap().

yrs,
--

-- 
Nick
Permalink | Reply | 1 comment |
headers
Lyes Amazouz | 8 May 2008 17:23
Picon

how to compile under cygwin


Hello list,
I want to make running my application, which is a sipmle file server,  under cygwin. It compiles well and I can run it. But when I try to make a request on it, it makes a "segementation fault" error.
Have I missed something in the compilation? how can I correct this.
 
This application has ran very well under Linux system. Has the libevent missed some considerations under cygwin?
--
===========
  |   Lyes Amazouz
  |   USTHB, Algiers
=========== 
_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 3 comments |
headers
Nick Mathewson | 8 May 2008 17:29

Re: how to compile under cygwin

On Thu, May 08, 2008 at 05:23:27PM +0200, Lyes Amazouz wrote:
> Hello list,
> I want to make running my application, which is a sipmle file server,  under
> cygwin. It compiles well and I can run it. But when I try to make a request
> on it, it makes a "segementation fault" error.
> Have I missed something in the compilation? how can I correct this.
> 
> This application has ran very well under Linux system. Has the libevent
> missed some considerations under cygwin?

I haven't tried cygwin in a while, but it used to work fine.  To learn
more about where the bug is here, it might help if you can get a stack
trace (using gdb) to figure out where the segfault is occurring.
Also, if you can send a very small example thing that reproduces the
bug for you, that would help too.

Finally, make sure you're using Libevent 1.4.3 (or wait for Libevent
1.4.4, which should come out in the next 48 hours): they should be way
less buggy than many older versions.

yrs,
--

-- 
Nick
Permalink | Reply | 2 comments |
headers
Lyes Amazouz | 8 May 2008 18:14
Picon

Re: how to compile under cygwin



On 5/8/08, Nick Mathewson <nickm <at> freehaven.net> wrote:
I haven't tried cygwin in a while, but it used to work fine.  To learn
more about where the bug is here, it might help if you can get a stack
trace (using gdb) to figure out where the segfault is occurring.
Also, if you can send a very small example thing that reproduces the
bug for you, that would help too.

Finally, make sure you're using Libevent 1.4.3 (or wait for Libevent
1.4.4, which should come out in the next 48 hours): they should be way
less buggy than many older versions.

yrs,
--
Nick
Hi,

Thanks for you quick reponse. I'll wait for 1.4.4. In the mean time, could
you please find
a complete GDB and STRACE logs (attached).

All the best
Lyes

1) GDB TRACE:

1.1) Start GDB:

$ gdb app/warcserver.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r -i 10.211.55.4 -p 7777 -x tmp
Starting program: /cygdrive/c/warc-tools-read-only/app/warcserver.exe -i
10.211.55.4 -p 7777 -x tmp
[New thread 532.0xa7c]
[New thread 532.0xf7c]
Starting the WARC Server ...

1.2) Send a request :

curl http://10.211.55.4:7777/WARC/0.17

1.3) Return to GDB:

[New thread 532.0x8c0]
     10 [main] warcserver 532 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
    989 [main] warcserver 532 open_stackdumpfile: Dumping stack trace to
warcserver.exe.stackdump
210501 [main] warcserver 532 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
211948 [main] warcserver 532 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)

Program received signal SIGSEGV, Segmentation fault.
0x61016583 in stack_info::walk () from /usr/bin/cygwin1.dll
(gdb) backtrace
#0  0x61016583 in stack_info::walk () from /usr/bin/cygwin1.dll
#1  0x7c859bb0 in OutputDebugStringA () from
/cygdrive/c/WINDOWS/system32/kernel32.dll
#2  0x40010006 in ?? ()
#3  0x00000000 in ?? ()
(gdb)

1.4) Please find attached the coredump (warcserver.exe.stackdump)


2) STRACE:

2.1) Launch the application with STRACE:

$ strace  ./app/warcserver.exe -i 10.211.55.4 -p 7777 -x tmp
&>warcserver.exe.strace

2398351 [main] warcserver 4044 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
2567102 [main] warcserver 4044 open_stackdumpfile: Dumping stack trace to
warcserver.exe.stackdump
2756096 [main] warcserver 4044 _cygtls::handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
2758951 [main] warcserver 4044 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)

2.2) Please find attached the STRACE log (warcserver.exe.strace)


--
===========
  |   Lyes Amazouz
  |   USTHB, Algiers
===========
Attachment (warcserver[1].exe.stackdump.zip): application/zip, 752 bytes
Attachment (warcserver[1].exe.strace.zip): application/zip, 9 KiB
_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 1 comment |

Gmane