Re: [Libevent-users] UDP Support

UDP works fine in libevent. I have several UDP based applications that run solely over UDP. You might have to run edge triggered to support UDP. I know I had to move to edge triggered, though I can't recall if that was for UDP, or for the OS I was using, or a combination. - scott Sent from

Re: [Libevent-users] event_del and already 'in-flight' event triggers

On Jul 5, 2012, at 4:20 PM, Nick Mathewson wrote: > On Thu, Jul 5, 2012 at 3:34 PM, Scott Dorr wrote: >> When an event_del() is called on an evq, what happens to triggerings that >> were already 'in-flight' but haven't had their callbacks called yet. > > e

[Libevent-users] event_del and already 'in-flight' event triggers

When an event_del() is called on an evq, what happens to triggerings that were already 'in-flight' but haven't had their callbacks called yet. For example: read event R is active on fd 42, uses 'callback_func()' as its callback new packet P1 comes in on fd 42 new packet P2 comes in on fd 42 libe

[Libevent-users] max number of supported events?

Is there an upper limit to the amount of outstanding events you can queue up on a base? (and if so, is there a difference between using an explicit base vs. the default base for this limit?) I'm trying to track down an issue where it feels like I'm losing events -- this is on a very heavily tr

[Libevent-users] max number of supported events?

Is there an upper limit to the amount of outstanding events you can queue up on a base? (and if so, is there a difference between using an explicit base vs. the default base for this limit?) I'm trying to track down an issue where it feels like I'm losing events -- this is on a very heavily tr

[Libevent-users] Mixing ssl bufferevents with normal events

I have a libevent based server that used to use a custom ssl wrapper to handle ssl traffic. This server takes ssl traffic on one end and speaks non-crypto on the other end. For a variety of reasons, the switch was made to use the built in ssl bufferevents to handle the ssl portion. The non-cryp

Re: [Libevent-users] Unitialized Memory Read when pushing >64 events at once

Sorry I didn't get a chance to fiddle with this until just now. The short program below does generate uninitialized memory reads when executing the printf(). If I add a memset() right after the events[200] declaration (before the epoll_wait() call), the uninitialized memory issue goes away, thoug

[Libevent-users] Unitialized Memory Read when pushing >64 events at once

Purify complains about Unitialized Memory Reads when I try to push more than 64 events onto the queue at the same time. This is in a 64bit application running on RHEL linux. I'm currently using libevent-2.0.10-stable. epoll_dispatch triggers a set of of 4 UMRs for each event past the 64th that I

Re: [Libevent-users] event base: multi-thread producers, single thread consumer?

On Fri, Apr 22, 2011 at 11:43 AM, Nick Mathewson wrote: > On Thu, Apr 21, 2011 at 6:29 PM, Scott Dorr > wrote: > > I've got a server with multiple threads, each with their own event base. > > Works wonderfully. I have a new situation that would be solved quite > &g

[Libevent-users] event base: multi-thread producers, single thread consumer?

I've got a server with multiple threads, each with their own event base. Works wonderfully. I have a new situation that would be solved quite easily if I could have all threads (but one) push events onto the event base for the final thread. That final thread will process events as they come up.