Hello,
A few months ago I discovered a problem with libevent and arm architecture.
I have TI DM355 board with montavista distribution, kernel
Linux testarm 2.6.10_mvl401 #8 Wed Mar 18 15:04:34 MSK 2009 armv5tejl unknown
My embedded libevent-based http server unexpectedly crashed. Then I
set
On Sun, Mar 08, 2009 at 07:28:58PM -0400, Nick Mathewson wrote:
On Sat, Mar 07, 2009 at 01:45:21PM -0500, Thor Lancelot Simon wrote:
[...]
I see two ways to handle this. One is with very, very nasty application
logic, and the other is to simply set two separate events with the SSL
fd,
On Fri, Mar 20, 2009 at 7:45 AM, Thor Lancelot Simon t...@panix.com wrote:
The first way is what you have to do with Libevent 1.4.x and earlier;
Libevent only supports one _pending_ event at a time per fd/operation
pair. In other words, it's okay to have two events set to watch
EV_WRITE on
On Fri, Mar 20, 2009, Dan Kegel wrote:
Just to clarify: I can add two events, one for EV_READ and one for
EV_WRITE, on the same FD, with different callbacks, and that _will_
work as expected?
Even if that works, isn't it inefficient at the syscall level somehow?
It can be. For things
On Fri, Mar 20, 2009 at 07:46:51AM -0700, Dan Kegel wrote:
On Fri, Mar 20, 2009 at 7:45 AM, Thor Lancelot Simon t...@panix.com wrote:
The first way is what you have to do with Libevent 1.4.x and earlier;
Libevent only supports one _pending_ event at a time per fd/operation
pair. ?In other
On Fri, Mar 20, 2009 at 08:13:05AM -0700, Dan Kegel wrote:
On Fri, Mar 20, 2009 at 8:06 AM, Thor Lancelot Simon t...@panix.com wrote:
Just to clarify: I can add two events, one for EV_READ and one for
EV_WRITE, on the same FD, with different callbacks, and that _will_
work as expected?
On Fri, Mar 20, 2009, Thor Lancelot Simon wrote:
Try doing it under strace and see what happens.
I seem to recall it caused one epoll syscall per event
on each time around the event loop.
Ugh. That sounds like a terrible limitation of epoll. A syscall
_per event_?
Once again I'm
It gives me great pleasure to be able to carp about the following
warning from valgrind:
==19138== Syscall param kevent(changelist) points to uninitialised byte(s)
==19138==at 0x24AD906: kevent (in /usr/lib/libSystem.B.dylib)
==19138==by 0x31274F: event_base_new (event.c:197)
...
On Fri, Mar 20, 2009, Dan Kegel wrote:
p.s. oh, yeah, I suppose I care about the error valgrind reported.
Does libevent
need to zero out some memory to avoid this?
Well, the same happens with linux epoll and valgrind. The thing is,
not all of the memory being passed into the syscall needs to
