Re: [Libevent-users] Multiple identical events on same fd in same loop

[Nick Mathewson]

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, each waiting on EV_WRITE.  So when the SSL fd comes ready for write --
 I'd hope -- both my pending SSL_read() and my pending SSL_write() would
 be invoked, each from a separate event's callback.

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 the same FD, but you can only ever add one at a time.

The application logic to handle this isn't actually so bad; instead of
having two events (one write, and one write in order to read),
have just one write for something event, and have your per-fd data
structure remember which underlying semantic events you actually
meant.  The Tor source code does this if you want to check out an
open-source example of how it's possible; I'm sure there are other
good projects to check out too.

On the other hand, the development branch for Libevent 2.0 _does_
support multiple events per fd; if you're willing to use alpha code
until Libevent 2.0 stabilizes, that might be one way to go.

(I'd also like to get a bufferevent filter that handles openssl into
Libevent 2.0, but the implementation for that one isn't done yet.)

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

Re: [Libevent-users] bug in epoll.c ?

[Nick Mathewson]

On Fri, Mar 06, 2009 at 10:20:02AM +0100, Alon Noy wrote:
 When I'm running my libevent based application under valgrind I'm
 getting messages about memory access violations in epoll.c. when
 changing line 125 from:
 
 nfiles = rl.rlim_cur - 1;
 
 to:
 
 nfiles = rl.rlim_cur;
 
 then the application runs with no complains from valgrind. The problems
 shows when reaching the limit of allowed open file descriptors.
 

Hm!  I suppose there's nothing necessarily wrong with omitting the -1
on non-Solaris platforms, if the goal is to be able to run right up to
rlim_cur active fds.  Out of curiosity, what was the valgrind error
you were seeing?

 From the remark above this line I understand that the -1 was hacked in
 because some issue with Solaris but was it ever tested with other
 platforms?

Yes.  I develop on Linux and OS X, and IIRC Niels is pretty eclectic
about his OS choices.  It would be neat to have a regression test for
this case, if you have the time to write one.

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