Re: [Libevent-users] Success compile libevent 1.4.3 with VC6

[Nick Mathewson]

On Wed, Apr 23, 2008 at 05:34:04PM +0400, Eugene 'HMage' Bujak wrote:
> Hi,
> 
> I want to submit a more complete patch for VC6.
> 
> This one makes all elements of the code compilable and this code is
> being used on a production-level project at work.
> 
> The patch is in attachment. Compiles and works under VC6.
> * signal_test works.
> * timer_test works.
> * event_test fails due to the reason that win32 select() can't work on
> anything but network sockets.
> 
> Most importantly, my code that runs perfectly well on unix (linux &
> freebsd) now runs on windows with little modification.
> 
> But:
> * Didn't try to run any other tests since there are no project files for
> them.
> * Didn't test how mingw32 copes with these changes either.

Okay, I've gone through this patch again, under VC++2005.  I think my
earlier issues still stand, so here's where we are:

> The main changes are:
> * INPUT and OUTPUT are defined in platform SDK, so I had to redefine
> them as EVRPC_INPUT and EVRPC_OUTPUT.

See notes in previous patch.

> * uint64_t on MSVC must be defined as unsigned __int64
> * int64_t on MSVC is to be defined as signed __int64

Should be fixed.

> * MSVC6 doesn't know about __func__ and the #ifdefs weren't guarding
> against them good enough.

This is just the changes in the sample dir, right?  As near as I can
tell, the change in config.h shouldn't be necessary, yes?

> * winsock2.h sometimes was included after windows.h, that lead to
> compiler errors in libevent.

Fixed.

> * select.c can be painlessly excluded from compilation in win32, but I
> still fixed it's compilation.

There's no point in including it; it shouldn't be in the win32 project.

> * Winsock library needs to be initialized and freed explicitly on win32.

Haven't applied yet.

> * http.c was using sockaddr_storage. There isn't one in MSVC. Using
> sockaddr is good enough for MSVC.

Checking for msc isn't right here: newer sdks do indeed seem to define
sockaddr_storage.

> * There are tons of compiler warnings regarding "do {} while(0);"

Sorry, which part fixes this?

> * I took the liberty to add #pragma to the WIN32-section of the event.h
> so that there's no need to put ws2_32 library into the linker explicitly.
> * There's no NFDBITS in msvc.

Shouldn't be needed if we don't use the select.c file.

> * vsnprintf() is _vsnprintf() for some weird reason on win32.

Actually, this underscores a deeper problem.  Windows vsnprintf
returns -1 if the result is too big for the buffer, but this is not
what libevent expects in a lot of places.  We need to solve this one.
I'm filing a bug here so we don't forget about it.

> * I've had to bump tv->tv_usec to 1000 to prevent eating 100% of the cpu
> core in win32 dispatch when using timers with events each 10ms or so.

Hm?  If the timers are happening every 10 ms, then the usec field
should be at least 1 already.  If there's a small example here to
help me wrap my head around the problem, that would be great.

> * Also I've provided a gettimeofday() wrapper that uses timeGetTime()
> instead of much slower _ftime().

Unfortunately, this will probably turn out to give unreliable results,
as it wraps every 49 days.  Thus, roughly 1 day out of 50, users'
timers will all go off way too early or not at all, depending.  Still,
it's a shame to use a slow time interface.  I hear
GetSystemTimeAsFileTime() [or whatever it's called] has a high
resolution, but I hear it preforms badly on win9x.  Perhaps if we're
feeling nutty, we could cobble something monotonic together out of
time() and timeGetTime(), like:

 int
 fake_gettimeofday(struct timeval *tv, struct timezone *tz) {
 /* Threadsafety? What threadsafety?  Also, not tested. */

 static DWORD last_timeGetTime_result = 0;
 static long seconds_offset = 0;

 DWORD now = timeGetTime();
 time_t seconds = now / 1000;
 if (!seconds_offset || now < last_timeGetTime_result) {
 /* Called for the first time, or wrapping around. */
 seconds_offset = time(NULL) - seconds;
 }
 tv->tv_sec = seconds + seconds_offset;
 tv->tv_usec = (now % 1000) * 1000;
 last_timeGetTime_result = now;
 return 0;
 }


In any case, 1.4.4 will call gettimeofday a lot less frequently than
1.4.3; maybe the ftime() call won't hurt as much now?
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: [Libevent-users] FYI: libevent/libev benchmark updated for libevent-1.4.3

[Nick Mathewson]

On Thu, May 08, 2008 at 05:05:20PM -0500, Dan wrote:
> 
> 
> Its to bad when people write emails like this, clearly no social skills.

Dan, please take this off-list.  This kind of flamewar does not help
libevent, libev, or anybody.

yrs,
-- 
Nick
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: [Libevent-users] FYI: libevent/libev benchmark updated for libevent-1.4.3

[Dan]

Its to bad when people write emails like this, clearly no social skills.
Yeah I suggested I was a noob just to see if he was an asshole, and guess 
what! :) Have a couple emails as well of him making personal attacks 
against my family and such, its really to bad, I feel sorry for him, but 
I'll leave it at that...



Dan.


On Thu, 8 May 2008, Marc Lehmann wrote:


On Thu, May 08, 2008 at 12:03:06AM -0500, Dan <[EMAIL PROTECTED]> wrote:

Think I tried Ev once, to many bugs, hell couldn't even set a timer within
a timer as I remember,


In no release ever was there such a bug. libev and EV are used in many
production environments and projects, too and have proven their stability
by now.

FYI: This dan guy is not an unknown, he regularly trolls, and has proven
many times that he has no clue of programming, how to pass arguments
etc.. This is from his earlier mails:

From: Dan <[EMAIL PROTECTED]>
Date: Sun, 20 Apr 2008 01:55:04 -0500 (CDT)
#> Like your perl EV module but kinda pointless without letting us have args.
#>
#> need to do $blah->blah($a,$b,\%c,[EMAIL PROTECTED]);
#>
#> I notice new version out of libeventare you going to maintain this?
#> Like to make this my event library

(So his main problem was not having a clue about the programming language
he wanted to use, namely Perl).

From: Dan <[EMAIL PROTECTED]>
Date: Sun, 20 Apr 2008 23:39:56 -0500 (CDT)
#> Sorry I am abit of a noob to events still. I been doing alot of research
#> on what the fastest, best module would be to use and yours seems like it
#> would be by far the fastest and use the least memory.
[...]
#> What I thought I would do is use your excellent module and use events.

So back then it was an excellent module for you, that is, until I told you to
read a good book about perl first.

Apparently, you don't want to improve your programming skills, lieing
about other people's work is enough for you. Try again.


This EV stuff just meant to undermine the hardwork of the folks at
libevent?


No, you are just an idiot, and a bad liar and top.

The benchmark document explains exactly how these timings were derived
and how to reproduce them, including the source to the benchmark, exact
version numbers for the libraires used, compiler flags etc., for everybody
to verify. If you don't believe the numbers you can verify them yourself,
as well as the validity of the benchmark numbers and the implementation.

You are certainly not doing the libevent developers any good by trolling
and spreading lies: I am sure they don't need the support of fanboys like
you.

--
   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: useful sendfile for HTTP servers (1.4.3-stable)

[William Ahern]

On Thu, May 08, 2008 at 10:33:21AM -0400, Nick Mathewson wrote:
> 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().

On Linux, I'd bet that AIO+splice can beat sendfile. The problem with
sendfile is that it can still block on file I/O. This is one major reason
why sendfile is no good for multimedia servers, _unless_ you're willing to
juggle and manage multiple threads (w/ the headache of profiling access
patterns and adjusting number of threads). On Linux, though, you could have
one thread doing kernel AIO from a file into a pipe using vmsplice, and a
second thread running the event loop (or N+M threads, where N is your number
of cores--an easier calculation.)

This leads into the second issue, which is how best to manage vmsplice
buffers, which needs to be page aligned, and have certain ownership
restrictions.

The upside is that it's the only feasible way in any unix (that I'm aware
of) to actually get a page of file data into a buffer without worrying about
(a) blocking, (b) dealing with POSIX AIO readiness signalling, or (c)
copying the data. _Also_, this allows a potential single code pathway for
either encrypted or plaintext I/O; for encrypted you'd just insert a filter,
and write the new data to a new page buffer. (Given all the recent political
"issues" lately, it's disconcerting that more people are giving thought to
moving the net toward ubiquitous encryption; including reducing the overhead
so there are few excuses.)

One caveat w/ the non-blocking splice setup is how to handle seeking. But
that can be dealt with as a matter of course.

Anyhow, next month I'll have some code and hopefully some numbers.

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Fwd: [Libevent-users] how to compile under cygwin

[Lyes Amazouz]

-- Forwarded message --
From: Lyes Amazouz <[EMAIL PROTECTED]>
Date: May 8, 2008 6:14 PM
Subject: Re: [Libevent-users] how to compile under cygwin
To: Nick Mathewson <[EMAIL PROTECTED]>, Lyes Amazouz <[EMAIL PROTECTED]>,
libevent-users@monkey.org



On 5/8/08, Nick Mathewson <[EMAIL PROTECTED]> 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
>
Sorry, this message is to be before the rattachements:

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 
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  -x tmp
Starting program: /cygdrive/c/warc-tools-read-only/app/warcserver.exe -i
10.211.55.4 -p  -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:/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  0x 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  -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
===



-- 
===
  |   Lyes Amazouz
  |   USTHB, Algiers
===
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: [Libevent-users] how to compile under cygwin

[Nick Mathewson]

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
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

[Libevent-users] how to compile under cygwin

[Lyes Amazouz]

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@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: [Libevent-users] Patch: useful sendfile for HTTP servers (1.4.3-stable)

[Nick Mathewson]

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
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

[Libevent-users] Error of evsigcaught

[Jass Zhao]

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 }

Thanks,
Peng
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users